“混蛋注射”和“穷人注射”之间的真正区别是什么？

从“.NET中的dependency injection”一书中，我知道应该在应用程序的Composition Root上创build对象图，这在使用IoC容器时对我很有意义。

在所有应用程序中，当我尝试使用DI时，总会有两个构造函数：一个是依赖关系的参数，另一个是没有参数的“默认”构造函数，然后调用另一个“新build”所有的依赖关系，但在上述书中，这被称为“混蛋注入反模式”，这就是我所知道的“穷人的注射”。

现在考虑这一切，我会说，“穷人的注入”只是不使用IoC容器，而是用手在所述组合根上编码所有的对象图。

所以我的问题是：

1. 我是否正确理解这些概念，还是完全偏离轨道？
2. 如果仍然需要在IoC容器中注册所有依赖关系，而不是使用完全相同的Composition Root对它们进行编码，那么使用IoC容器的真正好处是什么？
3. 如果我误解了“穷人注射”究竟是什么，请问有人能澄清吗？

谢谢

Answer 1

谈到DI，在这里有很多相互冲突的用法。 “ 穷人的DI”一词也不例外。 对某些人来说，这意味着一件事，而对另一些人则意味着不同的事物。

我想要做的一件事就是为DI提供一致的模式语言。 当谈到所有这些使用相冲突的术语时，我有两个select：提出一个全新的术语，或select最普遍的用法（根据我的主观判断）。

一般来说，我宁愿重复使用现有的术语，而不是组成一个全新的（因此是外来的）模式语言。 这意味着在某些情况下（比如“穷人的DI”），您可能会对这个名字的概念有不同的概念。 这通常发生在模式书籍上。

至less我觉得这本书似乎已经完成了解释穷人的DI和Bastard Injection的工作，因为在OP中给出的解释是现实的。

关于DI容器的真正好处，我会引用你这个答案： 控制容器反转的论据

Answer 2

对问题第2）部分的一些注释。

如果仍然需要在IoC容器中注册所有依赖关系，而不是使用完全相同的Composition Root对它们进行编码，那么使用IoC容器的真正好处是什么？

• 如果你有一个依赖关系树（依赖于依赖关系依赖于其他依赖关系的依赖关系等等）：你不能在组合根中完成所有的“新闻”，因为你在每个“混蛋注入”每个类的构造函数，所以有很多“构图根”沿着你的代码库传播

• 如果你有一棵依赖关系树，使用一个IoC容器将无需input一些代码。 想象一下，你有20个不同的类，依赖于相同的IDependency 。 如果您使用容器，则可以提供一个configuration，让它知道哪个实例用于IDependency 。 你将在一个地方做到这一点，容器将小心提供所有相关类的实例

• 容器也可以控制对象的生命周期，这提供了另一个优点。

除了DI（可testing性，可维护性，代码解密，可扩展性…）提供的其他明显优势之外，