IOC容器的最佳实践

Ryu*_*Ryu 26 c# inversion-of-control unity-container

我正在使用Unity IOC容器,我只是想知道访问多个类的容器的最佳方法是什么.

每个类都应该有一个IUnityContainer成员,然后通过构造函数传递容器吗?是否应该有一个带有IOC容器的单例类?

asp.net开发怎么样?

有人可以指导我朝正确的方向发展吗?谢谢.

Tho*_*enz 22

恕我直言,不建议将整个容器注入类或具有应用程序范围的静态IoC服务定位器.

您希望能够从类的构造函数中看到(让我们称之为Foo),它使用什么样的服务/对象来完成工作.这提高了透明度,可测试性和可脱气性.

让我们说Foo只需要电子邮件服务,但我传入整个容器和代码中的某个地方,电子邮件服务从容器中解析出来.在这种情况下,将很难遵循.相反,最好将电子邮件服务直接注入状态Foo的依赖关系更清晰.

如果Foo需要创建电子邮件服务的多个实例,最好创建并注入一个EmailServiceFactory(通过IoC容器),它将动态创建所需的实例.

在后一种情况下,Foo的依赖关系仍然表示尽可能具体 - 只有EmailServiceFactory可以创建的依赖关系.如果我注入了整个容器,那就不清楚它提供的服务是Foo的确切依赖.

现在,如果我以后想要提供电子邮件服务的不同实例,我会在EmailServiceFactory中交换它.如果它所创建的所有服务都需要交换(例如在测试期间),我也可以换掉整个工厂.

因此,以创建一个额外的类(工厂)为代价,我获得了更清晰的代码,并且不必担心使用全局静态时可能发生的奇怪错误.另外,在提供测试的模拟时,我确切地知道它需要什么模拟,而不必模拟整个容器的类型.

这种方法也具有优势,现在,当模块初始化时(仅适用于Prism/Modularity),它不必注册它提供给IoC容器的所有类型的对象.相反,它只能注册其ServiceFactory然后提供这些对象.

需要明确的是,模块的初始化类(实现IModule)仍然应该在其构造函数中接收应用程序范围的IoC容器,以便提供其他模块使用的服务,但容器不应该侵入模块的类.

最后,我们这里有一个额外的间接层如何解决问题的另一个很好的例子.


Ryu*_*Ryu 13

将IOC容器放在进程中的最高级别/入口点,并使用它将依赖项注入其下的所有内容.


lcv*_*nny 6

你可以在容器中注册容器并像其他依赖属性一样注入容器,如下所示:

IUnityContainer container = new UnityContainer();
container.RegisterInstance<IUnityContainer>(container);
Run Code Online (Sandbox Code Playgroud)

需要访问它的类将具有以下属性:

private IUnityContainer unityContainer;
[Dependency]
public IUnityContainer UnityContainer
{
    get { return unityContainer; }
    set { unityContainer = value; }
}
Run Code Online (Sandbox Code Playgroud)

因此,只要解决/建立了这种类的实例,就注入容器.

这更灵活,因为它适用于同一应用程序中的多个容器,而使用单例模式是不可能的.

  • Unity容器自动注册自己的IUnityContainer,年轻的草料斗. (4认同)