ioc-container - IoC 容器使用的反模式。为什么 IoC 容器如此复杂且使用如此 "fancy"方式？

Question

我开始认真考虑使用 IoC 容器会引发创建过度设计的解决方案(至少它会促使我尝试使用各种不必要的功能:)。

是时候将我的“IoC”反模式列表与社区列表同步了。

我短暂的经验告诉我们，在启动时每个应用程序调用一次 Resolve 方法来解决一些基础设施单例并用它们启动“ transient 对象工厂”就足够了，这可以产生新的“更小的生命周期 Cereal 工厂”。即使使这些工厂线程安全(例如，每个线程创建一个实例)也很容易通过在工厂中添加 10 行代码来实现……但这些工厂仍然比“库与 IoC 工具的集成”简单得多。拦截？只需创建自己的包装器...终身管理器/依赖策略/父容器？仅在 Bootstrap 中调用 Resolve 一次，您就不会考虑这一点。

你能帮我理解为什么开发人员在不同的应用程序层上多次调用 Resolve(通过传递容器或通过委托(delegate)传递给容器)然后有很多事情要考虑吗？我真的很担心我错过了什么。

Answer 1

某种 IoC 是反模式，或者在某些情况下可能是反模式。例如 service locator antipattern .但是，如果您在应用程序的开头使用构造函数注入(inject) - 并且仅存在于此 - 那么它不应该导致反模式。

在类中注入(inject) DI 容器接口(interface)是对构造函数注入(inject)的错误使用。如果 DI 不是你的类的业务逻辑的一部分，它不应该知道或依赖于 DI 容器，也不应该依赖于 IKitchen。将您的 DI 容器注入(inject)到与您的依赖注入(inject)容器一起工作的某种帮助程序或服务中是很好的，因为它的目的是使用或围绕 DI 容器工作。您提供的链接中的示例是滥用 IoC。这并不意味着 IoC 通常是一种反模式。

我认为正确的问题是“构造函数注入(inject)可以成为反模式吗？”。到目前为止，我从未遇到过任何情况或看到任何例子，所以我会说“不”，直到我遇到这种情况。