从《在.NET中的依赖注入》一书中，我知道应该在应用程序的合成根创建对象图，这对我在使用IOC容器时很有意义。

在我在尝试使用DI时看到的所有应用程序中，总是有两个构造函数：一个是以依赖项为参数的构造函数，另一个是"默认"的构造函数，没有参数的构造函数反过来调用另一个"更新"所有依赖项，但是在前面的书中，这被称为"bastard injection anti pattern"，并且这就是我以前所说的"穷人的注射"。

现在考虑到所有这些，我要说的是，"可怜人的注入"不会使用IOC容器，而是在所说的组成根上手工编码所有对象图。

所以我的问题是：

谢谢

当涉及到DI时，有很多术语的使用冲突。"穷人的DI"一词也不例外。对某些人来说，它意味着一件事，而对其他人来说，它意味着不同的事情。

我想用这本书做的事情之一是为DI提供一致的模式语言。当涉及到所有使用冲突的术语时，我有两个选择：提出一个全新的术语，或者选择最流行的用法(根据我的主观判断)。

一般来说，我更喜欢重复使用现有的术语，而不是组成一种全新的(因而是外来的)模式语言。这意味着在某些情况下(比如穷人的DI)，你可能对这个名字有不同的概念，而不是书中给出的定义。这经常发生在模式书上。

至少我觉得这本书似乎已经尽了自己的职责，准确地解释了穷人的注射毒品和私生子的注射，这让人安心，因为O.P.中给出的解释是正确的。

关于DI容器的真正好处，我将向您介绍以下答案：反对控制容器反转的论据

P.S.2018-04-13：我想指出的是，多年前我开始承认"穷人的DI做穷人"(sic！)沟通原则的本质的工作，所以多年来，现在，我把它称为纯DI。

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

If you still need to register all the dependencies in the IoC container vs. coding them by hand in the exact same Composition Root, what's the real benefit of using an IoC container?

• 如果您有一个依赖树(依赖依赖于依赖于其他依赖项的依赖项的clases等等)：您不能在一个组合根中做所有的"新闻"，因为您在每个类的每个"bastard injection"构造函数上都新建了实例，所以有许多"组合根"分布在您的代码基中。

• 无论您是否有依赖树，使用IOC容器都可以节省键入一些代码的时间。假设有20个不同的类依赖于同一个IDependency。如果使用容器，则可以提供一个配置，让它知道要为IDependency使用哪个实例。您将在一个地方进行此操作，容器将注意在所有依赖类中提供实例。

• 容器还可以控制对象的生存期，这提供了另一个优势。

所有这些，除了DI提供的其他明显优势(可测试性、可维护性、代码去耦、可扩展性…)

我们发现，在重构遗留应用程序和分离依赖关系时，使用两步流程往往更容易。这个过程包括"穷人"和正式的国际奥委会集装箱系统。

第一：建立接口，建立"穷人IOC"来实现。

• 这将在不增加开销(和学习)的情况下分离依赖关系国际奥委会正式设立的曲线。
• 这也减少了对现有遗留代码的干扰。没有什么比引入另一组要调试的问题更好的了。
• 开发团队成员的专业知识或理解水平绝不相同。因此，它节省了大量的实现时间。
• 这也为测试用例提供了基础。
• 这也为以后正式的IOC集装箱系统建立了标准。
• 这可以由许多人随着时间的推移逐步实现。

第二，每个国际奥委会制度都有利弊。

• 既然已经建立了一个应用标准，一个有教育意义的决定可以选择IOC集装箱系统。
• 实施国际奥委会制度成为一项将"穷人"代码与新的国际奥委会制度。
• 这可以随着时间的推移逐步实现，并与"穷人"并行。最好是一个人负责。