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

基于构造函数的依赖注入(没有神奇的“框架”的帮助)是构造OO代码的一种干净而有益的方式。在我所见过的最好的代码库中，经过多年与Martin Fowler的其他前同事的相处，我开始注意到大多数以这种方式编写的优秀类最终都只有一个doSomething方法。

那么，主要的缺点是，一旦您意识到这只是一种笨拙的、冗长的OO方式，将闭包编写为类，以获得函数式编程的好处，那么您编写OO代码的动机就会迅速消失。

控制反转(不是完全依赖注入，但已经足够接近了)最大的“缺点”是，它倾向于去掉一个点来查看一个算法的概述。这基本上就是当你有解耦的代码时所发生的事情——在一个地方查看的能力是紧密耦合的产物。

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

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

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

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

以下几点:

DI增加了复杂性，通常是通过增加类的数量，因为责任分离得更多，这并不总是有益的 您的代码将(在某种程度上)耦合到您使用的依赖注入框架(或者更一般地说，如何决定实现DI模式) 执行类型解析的DI容器或方法通常会导致轻微的运行时损失(非常可以忽略不计，但它确实存在)

通常，解耦的好处是使每个任务更易于阅读和理解，但增加了编排更复杂任务的复杂性。

它可以增加应用启动时间，因为IoC容器应该以适当的方式解析依赖关系，有时需要进行多次迭代。