IoC容器使用的反模式。为什么IoC容器如此复杂并以如此“花哨”的方式使用？

Question

我认真地开始认为使用IoC容器会激发创建过度设计的解决方案（至少它会激起我尝试使用各种不必要的功能:)。

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

我的简短经验告诉我们，在启动时每个应用程序调用一次Resolve方法就足以解决一些基础设施单例，并启动它们“瞬态对象的工厂”，这可能会产生新的“更小的终身粮食工厂”。通过在工厂中添加10个代码行，即使使这些工厂的线程安全（例如，为每个线程创建一个实例）也很容易实现......然而，这些工厂比“库与IoC工具的集成”要简单得多。拦截？只需创建自己的包装...终身经理/依赖策略/父容器？在bootstrapper只调用一次Resolve，你不会考虑这个。

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

Answer 1

当我不清楚如何使用IoC容器时，我决定停止使用它，因为我认为这只是对简单依赖注入的过度复杂。

虽然即使没有IoC也可能落入过度注射的情况。 前一段时间我读了ninject的作者的一些帖子，这些帖子让我开心。

如您所知，注入器应仅在上下文根目录中使用。但是，为了避免过度注入，我决定引入注入工厂规则的例外。

在我的框架中，工厂（和工厂）可以使用注射器容器。工厂在上下文根中的容器中绑定，因此可以注入。工厂成为有效的依赖项，用于在其他对象中创建新对象，使用注入器容器来促进依赖注入。

Answer 2

某些IoC是反模式或在某些情况下可能。例如service locator antipattern。但是如果你在应用程序的开头使用构造函数注入 - 并且只在那里 - 那么它应该不会导致反模式。

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

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

Answer 3

阅读This

显然有些不对劲。新库不应带来额外的复杂代码。

Answer 4

我找到了一个可能理解我的人：）

构造函数over-injection anti-pattern

Answer 5

我眼中的其他反模式正在推动容器的初始化“更深”，然后实际的启动器。

例如Unity and WCF recommendations

wcf app中的bootstrapper是服务构造函数，然后只是将容器初始化放到构造函数中。我不明白建议去编程wcf服务行为和客户服务主机工厂的原因：如果你想要“IoC容器免费”引导程序 - 这是荒谬的，如果你需要“IoC容器免费”服务合同实现 - 只需创建第二个“IoC容器免费”服务合同实现。