为您的IoC打包是一个好主意吗？ [英] Is having a wrapper for your IoC a good idea?

问题描述

我已经使用StructureMap一年多了。而且一直以来，我以前都有一个称为IoC的包装类，

I have been using StructureMap for more than a year now. And all this time I used to have a wrapper class called IoC which looked like this

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容器。

I added the wrapper assuming that I might want to change the IoC container at some point down the line. At this point I am thinking this is bad. One reason is: I cannot use ObjectFactory in my code to do other interesting things, I have to use this wrapper. The other thing is: Our code shouldn't really have to be independent of the DependencyInjection container.

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

What are the pros/cons of using this approach?

推荐答案

因此，公共服务定位符已开发项目。它是对DI框架的抽象，它定义了类似于 IoC 类的接口。我什至开发了简单服务定位器库； DI库，它是Common Service Locator接口的直接实现。

For this reason the Common Service Locator project has been developed. It is an abstraction over DI frameworks and it defines an interface much like your IoC class. I even developed the Simple Service Locator library; an DI library that is a direct implementation of the Common Service Locator interface.

因此，从这个意义上讲，对DI框架进行抽象并不奇怪。但是，当正确（并完全）执行依赖关系注入时，其想法是相应地调整应用程序的设计，在应用程序根目录中配置容器，并且最好在应用程序中仅将单个位置进行类型组装（请阅读： GetInstance 被调用）。对于ASP.NET MVC应用程序，这将是 ControllerFactory 。对于ASP.NET WebForms应用程序，通常需要覆盖 PageHandlerFactory 。

So in that sense, it's not weird to have an abstraction over DI frameworks. However, when doing Dependency Injection correctly (and completely), the idea is to adjust the design of your application accordingly, configure the container in the application root, and have preferably just a single place in the application were types are assembled (read: were GetInstance is called). For an ASP.NET MVC application, this would be the ControllerFactory. For ASP.NET WebForms application you would typically need to override a PageHandlerFactory.

按照这些规则进行操作，没有理由使用这种抽象，因为无论如何您只是在应用程序中的单个位置调用了容器。但是，如果这对您不可行，则可以使用通用服务定位器或您自己的抽象方法。

When you play by these rules, there is no reason to use such an abstraction, because you just call the container at a single place in your application anyway. However, if that's not feasible for you, using either the Common Service Locator or your own abstraction is an alternative.

但是在决定让代码依赖IoC库的抽象之前，请退后一步，因为这会导致很多问题，并且通常被视为反模式。从代码中回调容器：

But please take a step back before you decide to let your code depend on an abstraction over your IoC library, because this causes a lot of problems and is seen as an anti-pattern in general. Calling back into the container from within your code:

• 使代码难于测试。


• 
  
• 禁用编译时支持。


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

• Makes the code much harder to test.
• Hides dependencies instead making the code harder to read and maintain.
• Disables compile-time support.
• Disallows your dependency graphs to be verified by a tool.

这篇关于为您的IoC打包是一个好主意吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！