dependency-injection - 为您的 IoC 提供包装器是个好主意吗？

Question

我已经使用 StructureMap 一年多了。一直以来，我都有一个名为 IoC 的包装类，它看起来像这样

class IoC {
    public static T GetInstance<T>()
    {
        return (T)GetInstance(typeof(T));
    }
    public static IEnumerable<T> GetAllInstances<T>()
    {
        return ObjectFactory.GetAllInstances<T>();
    }

    public static IEnumerable GetAllInstances(Type type)
    {
        return ObjectFactory.GetAllInstances(type);
    }

    public static object GetInstance(Type type)
    {
        return ObjectFactory.GetInstance(type);
    }

    public static void Inject<T>(T obj)
    {
        ObjectFactory.Inject(obj);
    }
}

我添加了包装器，假设我可能想在某个时间点更改 IoC 容器。在这一点上，我认为这很糟糕。一个原因是:我不能在我的代码中使用 ObjectFactory 来做其他有趣的事情，我必须使用这个包装器。另一件事是:我们的代码不应该真正独立于 DependencyInjection 容器。

使用这种方法的优点/缺点是什么？

Answer 1

出于这个原因，Common Service Locator项目已开发。它是对 DI 框架的抽象，它定义了一个与您的 IoC 非常相似的接口(interface)。类(class)。我什至开发了Simple Service Locator图书馆;一个直接实现 Common Service Locator 接口(interface)的 DI 库。

所以从这个意义上说，对 DI 框架进行抽象并不奇怪。但是，当正确(并且完全)进行依赖注入(inject)时，想法是相应地调整应用程序的设计，在应用程序根目录中配置容器，并且最好在应用程序中只有一个位置来组装类型(阅读: GetInstance 被调用)。对于 ASP.NET MVC 应用程序，这将是 ControllerFactory .对于 ASP.NET WebForms 应用程序，您通常需要覆盖 PageHandlerFactory .

当您遵守这些规则时，没有理由使用这样的抽象，因为无论如何您只是在应用程序中的一个位置调用容器。但是，如果这对您不可行，请使用 Common Service Locator或者您自己的抽象是另一种选择。

但是，在您决定让您的代码依赖于 IoC 库的抽象之前，请退后一步，因为这会导致很多问题和 is seen as an anti-pattern一般来说。从代码中回调容器:

使代码更难测试。

隐藏依赖项，而不是使代码更难阅读和维护。

禁用编译时支持。

不允许工具验证您的依赖关系图。