从“.Net中的依赖注入”一书中我知道应该在应用程序的组合根处创建对象图，这在我使用IoC时对我很有意义容器
在我尝试使用DI时所见到的所有应用程序中，始终有两个构造函数：一个以依赖为参数的构造函数和一个没有参数的“默认”构造函数，后者又调用另一个“新近”所有的依赖，但在上述书中，这被称为“Bastard Injection anti-pattern”，这就是我曾经称之为“穷人的注射”。
现在考虑所有这些，我会说“穷人注射”只是不使用IoC容器而是在所述组合根上手动编码所有对象图。
所以我的问题是：
由于
答案 0 :(得分：51)
说到DI，那里的术语使用很多。 穷人的DI 这个词也不例外。对某些人而言，这意味着一件事，而对于其他人则意味着不同的东西。
我想对本书做的一件事就是为DI提供一致的模式语言。当涉及到使用冲突的所有条款时，我有两个选择：提出一个全新的术语，或者选择最普遍的用法（根据我的主观判断）。
一般来说，我更喜欢重复使用现有的术语，而不是制作一种全新的（因此是外来的）模式语言。这意味着在某些情况下（例如穷人的DI），你可能对这个名称的概念与书中给出的定义有不同的概念。这通常发生在模式书籍上。
至少我发现它让人放心，这本书似乎已经完成了解释穷人的DI和Bastard注射的工作，因为O.P.中给出的解释是正确的。
关于DI容器的真正好处，我将引用您的答案：Arguments against Inversion of Control containers
P.S。 2018-04-13：我想指出，我多年前就已经开始认识到，穷人的DI 这个词做了一个糟糕的（原文如此！）的沟通工作这个原则的本质，所以多年来，现在，我instead called it Pure DI。
答案 1 :(得分：4)
问题的第2部分的一些注释。
如果您仍然需要在IoC容器中注册所有依赖项，而不是在完全相同的组合根中手动编码，那么使用IoC容器的真正好处是什么？
如果你有一个依赖树（clasess依赖于依赖于其他依赖关系的依赖关系等等）：你不能在组合根中做所有的“新闻”，因为你新建了实例在每个类的每个“混蛋注入”构造函数中，因此在您的代码库中传播了许多“组合根”
如果您有一个依赖树，或者没有，使用IoC容器将无需键入一些代码。想象一下，你有20个不同的类依赖于相同的IDependency。如果您使用容器，则可以提供配置以让它知道要用于IDependency的实例。您将在一个地方进行此操作，容器将注意在所有依赖类中提供实例
容器还可以控制对象的生命周期，这提供了另一个优势。
所有这一切，DI提供的其他明显优势（可测试性，可维护性，代码解耦，可扩展性......）
答案 2 :(得分：0)
我们发现，当重构遗留应用程序并解耦依赖关系时，通过两步过程完成操作往往会更容易。该过程包括“穷人”和正式的IoC容器系统。
首先：建立接口并建立“穷人ioc”以实现它们。
第二：每个IoC系统各有利弊。