在过去的6个月里，我一直在广泛使用Guice (Java DI框架)。虽然总的来说我认为它很棒(特别是从测试的角度来看)，但也有一些缺点。最值得注意的是:

Code can become harder to understand. Dependency injection can be used in very... creative... ways. For example I just came across some code that used a custom annotation to inject a certain IOStreams (eg: @Server1Stream, @Server2Stream). While this does work, and I'll admit has a certain elegance, it makes understanding the Guice injections a prerequisite to understanding the code. Higher learning curve when learning project. This is related to point 1. In order to understand how a project that uses dependency injection works, you need to understand both the dependency injection pattern and the specific framework. When I started at my current job I spent quite a few confused hours groking what Guice was doing behind the scenes. Constructors become large. Although this can be largely resolved with a default constructor or a factory. Errors can be obfuscated. My most recent example of this was I had a collision on 2 flag names. Guice swallowed the error silently and one of my flags wasn't initialized. Errors are pushed to run-time. If you configure your Guice module incorrectly (circular reference, bad binding, ...) most of the errors are not uncovered during compile-time. Instead, the errors are exposed when the program is actually run.

既然我已经抱怨过了。让我说，我将继续在我当前的项目中(很可能是在下一个项目中)使用Guice。依赖注入是一种非常强大的模式。但它肯定会让人困惑，无论你选择什么依赖注入框架，你几乎肯定会花一些时间咒骂。

另外，我同意其他发帖者的观点，依赖注入可能被过度使用。

仅仅通过实现依赖注入就实现了代码的解耦，而没有实际解耦。我认为这是DI最危险的地方。

两件事:

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

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

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

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

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

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

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

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

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

If you're using DI without an IoC container, the biggest downside is you quickly see how many dependencies your code actually has and how tightly coupled everything really is. ("But I thought it was a good design!") The natural progression is to move towards an IoC container which can take a little bit of time to learn and implement (not nearly as bad as the WPF learning curve, but it's not free either). The final downside is some developers will begin to write honest to goodness unit tests and it will take them time to figure it out. Devs who could previously crank something out in half a day will suddenly spend two days trying to figure out how to mock all of their dependencies.

类似于马克·西曼(Mark Seemann)的回答(现已删除;只有超过1万个声誉点)，底线是你花时间成为一个更好的开发人员，而不是把代码拼凑在一起，然后把它扔出去/投入生产。你的企业更愿意选择哪一种?只有你能回答这个问题。

有一件事让我对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>实例类作为依赖项。这将改变依赖对象的构造函数，并使其更加了解实现细节，例如对象构造开销，这也可以说是不可取的。