我已经使用统一为我的最后一个项目，并普遍高兴。但基准测试让我想到我可能会使用Simple Injector进行下一个项目。为什么Simple Injector不像Unity这样的IContainer抽象？
但是，简单喷油器似乎没有它的Container类的接口。这意味着，无论何时我想在方法中使用容器，我都不能嘲笑容器进行单元测试。
我很困惑如何真正基于接口功能的工具本身并不会为容器创建接口。我知道依赖注入的经典方法在启动时不需要容器。 （其余的部分使用构造函数注入。）但是我发现，当橡胶撞击道路时并不总是如此。有时你只需要容器就可以在代码中进行“解析”。
如果我使用Simple Injector，那么该代码似乎越来越难以进行单元测试。
我对不对？或者我错过了什么？
简单的喷油器不包含抽象，因为那将是无用的：
这将是无用的，简单的注射器来定义它， 因为你的代码将在这种情况下，仍取决于库（因为Simple Injector定义了抽象），并且这导致供应商锁定，该简单注射器为tries to prevent。
除了应用程序的Composition Root之外，您编写的任何代码不应取决于容器，也不应取决于容器的抽象。两者都是Service Locator anti-pattern的实现。
单元测试时，不应该使用DI库。在进行单元测试时，您应该手动在被测试的类中注入所有假或模拟对象。使用容器只会使事情复杂化。也许你正在使用一个容器，因为手动创建这些类对你来说太麻烦了。这可能表明您的代码存在问题（您可能违反了Single Responsibility Principle）或您的测试（您可能缺少factory method to create the class under test）。
您可能会将容器用于您的集成测试，但您首先应该没有那么多的集成测试。重点应放在单元测试上，应用依赖注入模式时应该很容易。最重要的是，与集成测试中隐藏容器相比，取决于非常宽的库定义的接口，有更好的方法。
你自己定义这样的接口（加上一个适配器）是微不足道的，证明它没有在库中。作为应用程序开发人员的职责是按照Dependency Inversion Principle的规定为您的应用程序定义正确的抽象。倾向于这样做的图书馆和框架在大多数情况下都会失败，无法提供适用于每个人的抽象概念。
库本身并不使用该抽象，根据Framework Design Guidelines，库应该不会为您定义这种抽象。如前所述，Simple Injector无论如何都会得到错误的抽象。
最后但并非最不重要的一点，Simple Injector容器实际上实现了System.IServiceProvider，它在mscorlib.dll中定义并可用于检索服务对象。
我不想在我的测试中使用容器。我想单元测试一个使用容器的方法。在这种情况下，我不能嘲笑容器不使用完整的SimpleInjector逻辑。 – Vaccano 2013-04-26 16:21:39
好的，我们将尝试这种与Unity不同的方式。对于Unity，我们嘲笑IContainer返回模拟。这样，我们的单元测试不会使用（测试）Unity。我们将尝试SimpleInjector。我们将容器的测试版本传递给被测对象的构造函数（在需要时）。该测试版本将设置为返回模拟。所以实质上，我们将在我们的测试中使用SimpleInjector东西来返回模拟，但是在生产中它将返回在启动时设置的对象。我觉得我必须尝试一下，因为SimpleInjector只是非常快速！ – Vaccano 2013-04-26 16:42:33
但是为什么这个类会依赖于容器？具有（足够）逻辑测试的类不应直接依赖于他的容器。只有基础结构组件（它们是组合根的一部分）应该对容器或容器的抽象有依赖关系。您显然无法测试您的系统，因为您违反了此规则。 – Steven 2013-04-26 21:51:13
我觉得这里给出的答案是完全在接受该服务定位是一个反模式，这反过来我不相信是全球公认的真正成立。请参阅Windows Workflow Foundation的扩展支持。
反模式链接（及其两个更新）也可能很弱...最新的更新声称违反了封装（“减轻了你必须理解你的每一段代码的每个实现细节的负担代码库“），然后同时宣称先验知识的依赖关系在声明方面与通过单元测试发现它们有所不同。无论哪种方式，你都需要知道该给它什么。总而言之，如果你想遵循定位器模式，可以利用它的IServiceProvider，或者简化你的容器群（单身），并为它创建一个静态包装器。
为什么不使用抽象工厂而不是注入容器？ – onof 2013-05-07 06:16:37