是一个静态类的实例包装器,用于DI反模式的目的吗?

时间:2012-02-08 09:49:12

标签: c# dependency-injection anti-patterns

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

我的想法是创建一个名为Injection的命名空间,并将该对象包装在一个带有接口的实例中,以便我可以将其注入。它还可以让我为需要更具体实现的存储处理程序换出存储处理程序。

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

作为一个注释,我想保留静态选项,不是每个人都需要或可以使用DI。我只是尝试以最少的重复次数启用它们。

2 个答案:

答案 0 :(得分:8)

你总是这么看。主要是处理已经静态或密封或未实现任何接口的遗留代码。虽然是基类而不是接口,HttpContextBase是我能想到的最突出的例子。

由于您希望保留静态选项,这基本上就是您当前所处的情况,因此请继续操作。但是,我不会创建一个Injection命名空间,因为该名称更多地讲述了机制而不是对象所扮演的角色。

你没有完全写出这个类是静态的,但我假设我们正在谈论一个静态方法的静态类。

稍微优雅的解决方案(如果你可以稍微更改一下)是将静态类转换为Singleton。然后它可以是静态的并同时实现接口:

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...
    }
}

我认为实现这样一个解决方案所需的唯一重构是使类本身具体化并使其以单例实现接口。

旧客户端仍然可以通过调用Foo.LegacyFoo();

来访问其方法

答案 1 :(得分:1)

在我看来,我会让依赖注入容器决定它是瞬态还是单例 - 我不知道你已经使用了什么框架,但是大多数框架应该控制依赖关系的生命周期 - 。

预依赖注入应用程序可以维护此对象的静态实例,作为某些应用程序范围的状态管理的一部分。