c# - 为了 DI 的目的，围绕静态类的实例包装器是一种反模式吗？

Question

我构建了一个小静态对象，用于将泛型类型保存到 WP7 上的独立存储。这适用于旧项目，但一些新项目使用 DI 来管理配置。我是 DI 的粉丝，因为它意味着我可以在一个地方更改配置并将其过滤到所有依赖项。

我的想法是创建一个名为 Injection 的命名空间，并将该对象包装在一个具有接口(interface)的实例中，以便我可以将其注入(inject)。它还将使我能够将存储处理程序换成需要更具体实现的存储处理程序。

这是常见做法还是反模式？

请注意，我想保留静态选项，因为不是每个人都需要或可以使用 DI。我只是想以最少的重复来启用两者。

Answer 1

你经常看到这个。大多数情况下，它是为了解决已经静态或密封或未实现任何接口(interface)的遗留代码。虽然是基类而不是接口(interface)，HttpContextBase是我能想到的最突出的例子。

既然你想保留静态选项，那基本上就是你目前所处的情况，那就去做吧。不过，我不会创建 Injection 命名空间，因为该名称更多地说明了机制，而不是对象所扮演的角色。

您没有写出该类如何是静态的，但我假设我们正在谈论一个带有静态方法的静态类。

一个稍微更优雅的解决方案(如果您可以稍微更改类)是将静态类变成单例。那么它可以是静态的，同时实现接口(interface):

public class Foo : IFoo
{
    private readonly static Foo instance = new Foo();

    private Foo() { }

    public static Foo Instance
    {
        get { return Foo.instance; }
    }

    // IFoo member:
    public void InterfaceFoo()
    {
        Foo.LegacyFoo();
    }

    public static void LegacyFoo()
    {
        // Implementation goes here...
    }
}

我认为达成这样的解决方案所需的唯一重构是使类本身具体化，并使其将接口(interface)实现为单例。

老客户仍然可以通过调用Foo.LegacyFoo();来访问它的方法