使用 IoC 进行生产和测试的最佳方式答案

【问题标题】：Best way of using IoC for production and Testing使用 IoC 进行生产和测试的最佳方式
【发布时间】：2012-01-05 10:19:48
【问题描述】：

当使用 IoC 进行依赖注入时，最推荐使用的是构造函数注入（如许多文章所述），我的问题是：
使用构造函数参数注入还是通过构造函数传递IoC容器以注入所需的类更好，什么对单元测试更有用？

【问题讨论】：

【解决方案1】：

虽然通过构造函数传递容器比让容器作为一个完整应用程序的单例访问要好，但它仍然是Service Locator (anti-pattern)的一种形式，不推荐使用。这有明显的缺点：

它使您的代码更难遵循。
当Single Responsibility Principle 被违反时，它变得不那么明显了（因为类隐藏了它所依赖的东西）。
这使得测试变得非常困难，因为您需要传递一个已配置的容器，并且您需要查看代码以了解测试需要什么。
当直接从每个类中向容器请求实例时，您将禁用 IOC 容器为您提供的许多功能，因为您不允许容器构建对象图。根据选择的框架，某些生活方式和功能（例如基于上下文的注入）将无法使用。
您的所有测试都使用容器实例，这使您的测试变得复杂，并且您的所有测试都依赖于 DI 框架，这使得在需要时切换到另一个框架非常昂贵。

只需将依赖项注入到构造函数中，而不是*容器本身。

_{*此规则的例外是此类位于应用程序的Composition Root 内。在这种情况下，它不被视为简单定位器模式，因为该类只是一个 infrastructure component。}

【讨论】：

【解决方案2】：

使用构造函数/属性注入更好。当您将 IOC 容器传递给构造函数时，您不再进行依赖注入和控制反转。您正在执行服务定位器模式。这意味着类不再让消费者注入它们的依赖项，而是试图获取它们。您也可能将您的代码绑定到某个特定的 DI 框架。

【讨论】：