IoC：使用静态 IoC 容器的依赖注入答案

【问题标题】：IoC: Dependency Injection with a static IoC containerIoC：使用静态 IoC 容器的依赖注入
【发布时间】：2012-07-11 15:52:20
【问题描述】：

把例如我可以访问的静态类中的 autofac/ninject 来自不同的程序集/项目？

静态类 MyContainer { 静态 IoCContainer ContainerOfCurrentRuntimeContext; }

如果我使用它，我可以在不同的项目中使用相同的 IoC 上下文。

【问题讨论】：

但是如果你这样做，就意味着你的代码的其他部分会调用它来获取实例，这与控制反转的含义完全相反。类不应该负责获取它们的依赖项。这些依赖项应该作为构造函数参数（构造函数注入）或属性（属性注入）传递。您的 DI 容器应仅在应用程序的一个位置可见，该位置通常是最外层的外壳。
@DarinDimitrov：不，这不是控制反转的反面。控制反转只是说我们应该与抽象对话，而不应该自己创建对象。然而，它与依赖注入相反。
请在 Stackoverflow 和 Google 中搜索“服务定位器反模式”。使用可全局访问的容器称为“服务定位器模式”，它被认为是一种反模式。

【解决方案1】：

不，这种方法会增加两个新问题：singleton 和 service locator 模式（都算作反模式）。结果，您的代码将耦合到新的依赖项：您的 DI 容器。

通常您可以克服使用服务定位器的限制，但这不值得这样做，因为为 DI 引入 composition root 非常简单。

顺便说一句，您可以拥有一种配置并在所有不同的项目中使用它。

【讨论】：

好的，谢谢。单一配置的要点：但在那种情况下，我不会得到相同的实例，不是吗？
是的，one 依赖注入 kernel（就 nIninject 而言）可以多次解析同一个依赖对象。这是通过声明特定的 scope 来完成的（就 nIninject 而言）。您可以指定 DI 每次在线程或 http 请求的范围内被请求时，都会从字面上注入相同的依赖项实例。您还可以定义自己的范围。