我开始认真考虑使用 IoC 容器会引发过度设计的解决方案（至少它会促使我尝试使用各种不必要的功能：）。
是时候将我的“IoC”反模式列表与社区的同步了..
我的短暂经验告诉我们，在每个应用程序启动时调用一次 Resolve 方法来解析一些基础设施单例并用它们启动“瞬态对象工厂”，这可以产生新的“更小的生命周期谷物工厂”，这绝对足够了。即使使这些工厂线程安全（例如，每个线程创建一个实例）也很容易通过在工厂中添加 10 行代码来实现......但这些工厂仍然比“库与 IoC 工具的集成”简单得多。拦截？只需创建自己的包装器...终身管理器/依赖策略/父容器？仅在引导程序中调用 Resolve 一次，您就不会考虑这一点。
您能否帮助我理解为什么开发人员在不同的应用程序层上多次调用 Resolve（通过传递容器或通过将委托传递给容器）然后有很多事情要考虑？我真的很担心我错过了什么。
【问题讨论】：
标签： ioc-container
某种 IoC 是反模式，或者在某些情况下可能是反模式。例如service locator antipattern。但是，如果您在应用程序的开头使用构造函数注入 - 并且仅在那里 - 那么它不应该导致反模式。
在类中注入 DI 容器接口是对构造函数注入的错误使用。如果 DI 不是你的类的业务逻辑的一部分，它不应该知道或依赖于 DI 容器，也不应该依赖于 IKitchen。将您的 DI 容器注入到与您的依赖注入容器一起工作的某种帮助程序或服务中是很好的，因为它的目的是使用或围绕 DI 容器工作。您提供的链接中的示例是滥用 IoC。这并不意味着 IoC 通常是一种反模式。
我认为正确的问题是“构造函数注入可以成为反模式吗？”。到目前为止，我从未遇到过任何情况或看到任何例子，所以我会说“不”，直到我遇到这种情况。
【讨论】：
当我不清楚如何使用 IoC 容器时，我决定停止使用它，因为我认为这只是简单的依赖注入过于复杂。
确实，即使没有 IoC，也有可能陷入过度注入的情况。 不久前，我读到了 ninject 的作者的一些帖子，让我大开眼界。
正如您已经知道的，注入器只能在上下文根中使用。但是，为了避免过度注入，我决定为注入工厂引入一个例外规则。
在我的框架中，工厂（并且只有工厂）可以使用注入器容器。工厂绑定在上下文根的容器中，因此可以被注入。工厂成为有效的依赖项，并用于在其他对象中创建新对象，使用注入器容器来促进依赖项注入。
【讨论】：
阅读This
显然出了点问题。新库不应带来额外的复杂代码。
【讨论】：
我找到了可能理解我的人:)
【讨论】：
在我看来，其他反模式是推动容器“更深”的初始化，然后是实际的引导程序。
例如Unity and WCF recommendations
wcf app 中的Bootstrapper 是服务的构造函数，然后把容器初始化放到构造函数中。我不明白为什么推荐去编程 wcf 服务行为和客户服务主机工厂：如果你想拥有“IoC 容器免费”引导程序 - 这是荒谬的，如果你需要“IoC 容器免费”服务合同实施 -只需创建第二个“IoC 容器免费”服务合同实施。
【讨论】：