如果您有一个自己开发的解决方案，依赖项就会在构造函数中直接出现。或者作为方法参数，这也不难发现。尽管框架管理的依赖关系，如果走到极端，就会开始变得像魔术一样。

然而，在太多的类中有太多的依赖项是一个明显的标志，说明你的类结构搞砸了。因此，在某种程度上，依赖注入(自行开发或框架管理)可以帮助发现那些可能隐藏在暗处的突出设计问题。

为了更好地说明第二点，这里是本文的一段摘录(原始来源)，我完全相信这是构建任何系统的基本问题，而不仅仅是计算机系统。

Suppose you want to design a college campus. You must delegate some of the design to the students and professors, otherwise the Physics building won't work well for the physics people. No architect knows enough about about what physics people need to do it all themselves. But you can't delegate the design of every room to its occupants, because then you'll get a giant pile of rubble. How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design? This is the architectural design problem Alexander is trying to solve, but it's also a fundamental problem of computer systems development.

DI能解决这个问题吗?不。但它确实帮助你清楚地看到，如果你试图把设计每个房间的责任委托给它的居住者。

代码可读性。由于依赖关系隐藏在XML文件中，因此您无法轻松地找出代码流。

这是我自己的第一反应:基本上任何模式都有同样的缺点。

学习是需要时间的 如果误解了，就会弊大于利 如果走到极端，工作量可能会超过收益

依赖注入是一种技术或模式，与任何框架无关。您可以手动连接依赖项。DI帮助您实现SR(单一职责)和SoC(关注点分离)。DI会带来更好的设计。从我的观点和经验来看，没有坏处。就像任何其他模式一样，你可能会弄错或误用它(但在DI的情况下很难)。

如果您使用框架将DI作为原则引入到遗留应用程序中，那么您可能犯的最大错误就是将其误用为服务定位器。DI+框架本身是伟大的，只是让事情变得更好，我看到它!从组织的角度来看，每一个新的过程、技术、模式……都有共同的问题:

你必须训练你的团队 您必须更改您的应用程序(这包括风险)

一般来说，你必须投入时间和金钱，除此之外，没有任何负面影响，真的!

没有任何DI的代码会面临众所周知的陷入意大利面条代码的风险——一些症状是类和方法太大，做太多，不容易更改、分解、重构或测试。

大量使用DI的代码可以是Ravioli代码，其中每个小类就像一个单独的Ravioli块——它只做一件小事，并且遵循单一责任原则，这是很好的。但是从类本身来看，很难看到系统作为一个整体在做什么，因为这取决于所有这些小部分是如何组合在一起的，这是很难看到的。它看起来就像一大堆小东西。

通过避免大型类中大量耦合代码的意大利面复杂性，您将面临另一种复杂性的风险，其中有许多简单的小类，它们之间的交互非常复杂。

我不认为这是一个致命的缺点- DI仍然是非常值得的。在某种程度上，小班级只做一件事的馄饨风格可能是好的。即使过度，我也不认为它像意大利面条代码那样糟糕。但是要避免它，第一步是要意识到它可能会走得太远。点击链接了解如何避免这种情况。

我发现构造函数注入会导致构造函数又大又丑(我在整个代码库中都使用它——也许我的对象太细了?)此外，有时使用构造函数注入会导致可怕的循环依赖(尽管这种情况非常罕见)，因此您可能会发现自己必须在更复杂的系统中拥有某种就绪状态生命周期，并进行几轮依赖注入。

然而，我更喜欢构造器注入而不是setter注入，因为一旦我的对象被构造，那么我就可以毫无疑问地知道它处于什么状态，它是在单元测试环境中还是加载到某个IOC容器中。这，以一种迂回的方式说，我觉得是setter注入的主要缺点。

(作为旁注，我确实发现整个主题相当“宗教”，但你的成就将随着开发团队的技术狂热程度而变化!)