有一件事让我对DI有点不安，那就是假设所有注入的对象都很容易实例化，而且不会产生副作用- or -依赖关系被频繁使用，以至于它超过了任何相关的实例化成本。

当依赖项在消费类中不经常使用时，这一点可能很重要;比如IExceptionLogHandlerService。显然，这样的服务很少在类中调用(希望:))——大概只在需要记录异常时调用;然而，规范的构造器-注入模式……

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

    ' ...
End Class

.．.要求提供该服务的“活动”实例，该死的成本/副作用。并不是说它可能会这样做，但是如果构建这个依赖实例涉及到服务/数据库命中，或配置文件查找，或在释放之前锁定资源，该怎么办呢?如果该服务是按需构建的、服务定位的或工厂生成的(它们都有各自的问题)，那么您将只在必要时才承担构建成本。

Now, it is a generally accepted software design principle that constructing an object is cheap and doesn't produce side-effects. And while that's a nice notion, it isn't always the case. Using typical constructor-injection however basically demands that this is the case. Meaning when you create an implementation of a dependency, you have to design it with DI in mind. Maybe you would have made object-construction more costly to obtain benefits elsewhere, but if this implementation is going to be injected, it will likely force you to reconsider that design.

顺便说一下，某些技术可以通过允许延迟加载注入的依赖项来缓解这个问题，例如，提供一个Lazy<IService>实例类作为依赖项。这将改变依赖对象的构造函数，并使其更加了解实现细节，例如对象构造开销，这也可以说是不可取的。

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

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

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

以下几点:

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

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

当您不断地使用技术来处理静态类型时，静态类型语言的假定好处似乎大大减少了。我刚刚采访的一家大型Java商店正在用静态代码分析绘制他们的构建依赖关系……它必须解析所有的Spring文件才能有效。

两件事:

它们需要额外的工具支持来检查配置是否有效。

例如，IntelliJ(商业版)支持检查Spring配置的有效性，并将标记出配置中的类型违反等错误。如果没有这种工具支持，就无法在运行测试之前检查配置是否有效。

这就是为什么“蛋糕”模式(Scala社区所熟知)是一个好主意的原因之一:组件之间的连接可以由类型检查器检查。而注释或XML则没有这种好处。

这使得程序的全局静态分析非常困难。

像Spring或Guice这样的框架很难静态地确定容器创建的对象图将是什么样子。尽管它们在容器启动时创建了一个对象图，但它们没有提供有用的api来描述将要创建的对象图。