穷人的依赖注入是将可测试性引入旧版应用程序的好方法吗？

在过去的一年中，我使用依赖注入和IOC容器创建了一个新系统。这教会了我很多关于DI的知识！

但是，即使在学习了概念和正确的模式之后，我仍然认为将代码解耦并将IOC容器引入旧版应用程序是一个挑战。该应用程序足够大，以至于真正的实现将是压倒性的。即使理解了价值并准予了时间。谁有时间抽出这样的东西？

当然，目标是将单元测试引入业务逻辑！
与防止测试的数据库调用交织在一起的业务逻辑。

我已经阅读了这些文章，并且了解了这篇Los Techies文章中描述的穷人依赖注入的危险。我了解它并没有真正分离任何东西。
我知道它可能涉及很多系统范围的重构，因为实现需要新的依赖项。我不会考虑在任何大小的新项目中使用它。

问题：可以使用穷人的DI 将可测试性引入旧版应用程序并开始滚动吗？

另外，使用穷人的DI作为真正依赖注入的基层方法是否是教育该原理的需求和收益的有价值的方法？

您是否可以重构具有数据库调用依赖关系的方法，并将该调用抽象到接口后面？简单地拥有这种抽象将使该方法可测试，因为可以通过构造函数重载传递模拟实现。

将来，一旦获得支持者的支持，就可以对该项目进行更新以实现IOC容器，并且构造函数将在那里使用抽象。

对NerdDinner中的“穷人注射”的批评与是否使用DI容器无关，而与正确设置类有关。

他们在文章中指出

public class SearchController : Controller {

    IDinnerRepository dinnerRepository;

    public SearchController() : this(new DinnerRepository()) { }

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

这是不正确的，因为尽管第一个构造函数的确提供了用于构造类的便捷后备机制，但它也创建了对的紧密依赖DinnerRepository。

正如Los Techies建议的那样，正确的补救措施当然不是添加DI容器，而是删除有问题的构造函数。

public class SearchController : Controller 
{
    IDinnerRepository dinnerRepository;

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

现在，其余类的依赖关系已正确反转。现在，您可以随意注入那些依赖项。

您在这里对“穷人的DI”是一个错误的假设。

创建一个具有“快捷方式”构造函数且仍会创建耦合的类并不是穷人的DI。

不使用容器，而是手动创建所有注入和映射，这是穷人的DI。

“穷人的DI”一词听起来很不好。因此，最近鼓励使用“ pure DI”一词，因为它听起来更积极，实际上更准确地描述了该过程。

使用穷人/纯DI来将DI引入现有应用程序中，这绝对是很好的方法，同时也是在许多新应用程序中使用DI的有效方法。正如您所说，在处理IoC容器的“魔术”责任之前，每个人都应该在至少一个项目上使用纯DI来真正理解DI的工作原理。

遗留团队/代码库中的Paragidm转换极具风险：

每当您建议对遗留代码进行“改进”并且团队中有 “传统”程序员时，您就是在告诉所有人“他们做错了”，并且在公司的余下时间成为“敌人”。

在任何情况下，使用DI框架作为锤子砸碎所有钉子只会使遗留代码变坏。这对个人而言也极具风险。

即使在像这样的最有限的情况下，它也可以在测试用例中使用，它们只会使那些测试用例成为“非标准”和“外来”代码，而这些代码充其量只会@Ignore在中断或恶化时被标记，甚至被不断抱怨。最有影响力的传统程序员会被“正确地”重写，而所有这些“浪费在单元测试上的时间”则完全归咎于您。

在一个业务应用程序中引入一个DI框架，甚至是“ Pure DI”的概念，更不用说大量的遗留代码库，而不会失去管理，团队，尤其是首席开发人员的赞助将是丧钟。在团队/公司上为您提供社交和政治支持。进行此类操作极具风险，并且可能以最坏的方式导致政治自杀。

依赖注入是一种寻找问题的解决方案。

如果您知道自己在做什么并且了解如何正确使用构造函数，则任何具有构造函数定义的语言都将按惯例使用依赖项注入，这就是很好的设计。

依赖注入仅在小剂量时适用于非常狭窄的范围：

• 更改很多或具有静态绑定的替代实现的事物。

  • JDBC驱动程序就是一个很好的例子。
  • HTTP客户端可能因平台而异。
  • 记录系统因平台而异。

• 具有可配置插件的插件系统，可以在框架的配置代码中定义这些插件系统，并在启动时自动发现它们，并在程序运行时动态加载/重新加载它们。