dependency-injection - 为什么 Simple Injector 没有像 Unity 这样的 IContainer 抽象？

Question

我在上一个项目中使用了 Unity，总体上很满意。但是基准测试让我认为我可能会在下一个项目中使用 Simple Injector。

但是，Simple Injector 似乎没有其Container 的接口(interface)。类(class)。这意味着每当我想在方法中使用容器时，我都无法模拟容器进行单元测试。

我很困惑一个真正基于接口(interface)起作用的工具，它本身不会成为容器的接口(interface)。我知道依赖注入(inject)的经典方法除了启动之外不需要容器。 (其余的使用构造函数注入(inject)。)但我发现当橡胶撞到路时，这并不总是正确的。有时您只需要容器就可以在代码中进行“解析”。

如果我使用 Simple Injector，那么该代码似乎更难进行单元测试。

我对吗？还是我错过了什么？

Answer 1

Simple Injector 不包含 IContainer 抽象，因为:

Simple Injector 定义是没用的，
因为在依赖 IContainer 而不是 Container 的情况下，您的代码在这种情况下仍将依赖于 Simple Injector，这会导致供应商锁定，即 Simple Injector tries to prevent。

除了应用程序的 Composition Root 之外，您编写的任何代码都不应该依赖于容器，也不应该依赖于容器的抽象。两者都是 Service Locator anti-pattern 的实现。

单元测试时不应使用 DI 库。在进行单元测试时，您应该在被测类中手动注入(inject)所有假对象或模拟对象。使用容器只会使事情复杂化。也许您正在使用容器，因为手动创建这些类对您来说太麻烦了。这可能表明您的代码(您可能违反了 Single Responsibility Principle )或您的测试(您可能缺少 factory method to create the class under test )存在问题。

你可能会使用容器进行集成测试，但你
首先不应该有那么多集成测试。重点应该放在单元测试上，这在应用依赖注入(inject)模式时应该很容易。最重要的是，与依赖非常广泛的库定义的接口(interface)相比，有更好的方法可以从集成测试中隐藏容器。

自己定义这样的接口(interface)(加上一个适配器)是微不足道的，这证明在库中没有它是合理的。作为应用程序开发人员，您的工作是为您的应用程序定义正确的抽象，如 Dependency Inversion Principle 所述。倾向于这样做的库和框架在大多数情况下都无法提供适用于所有人的抽象。

库本身不使用该抽象，根据 Framework Design Guidelines ，库应该在这种情况下不为您定义此类抽象。如前一点所述，Simple Injector 无论如何都会弄错抽象。

最后但同样重要的是，Simple Injector 容器确实实现了在 mscorlib.dll 中定义的 System.IServiceProvider，可用于检索服务对象。