我试图在工作中引入依赖注入(DI)模式，我们的一位主要开发人员想知道:如果有的话，使用依赖注入模式的缺点是什么?
注意，如果可能的话，我在这里寻找一个详尽的列表，而不是关于这个主题的主观讨论。
澄清:我谈论的是依赖注入模式(参见Martin Fowler的这篇文章)，而不是特定的框架，无论是基于xml的(如Spring)还是基于代码的(如Guice)，还是“自滚动”的框架。
Reddit的subreddit /r/programming上正在进行一些深入的讨论/咆哮/辩论。
当前回答
仅仅通过实现依赖注入就实现了代码的解耦，而没有实际解耦。我认为这是DI最危险的地方。
其他回答
代码可读性。由于依赖关系隐藏在XML文件中，因此您无法轻松地找出代码流。
仅仅通过实现依赖注入就实现了代码的解耦，而没有实际解耦。我认为这是DI最危险的地方。
我不认为存在这样的列表，但是试着阅读这些文章:
DI会模糊代码(如果你没有使用好的IDE) Bob叔叔认为，误用IoC会导致糟糕的代码。 需要注意过度设计和创造不必要的多功能性。
它可以增加应用启动时间，因为IoC容器应该以适当的方式解析依赖关系，有时需要进行多次迭代。
当您不断地使用技术来处理静态类型时，静态类型语言的假定好处似乎大大减少了。我刚刚采访的一家大型Java商店正在用静态代码分析绘制他们的构建依赖关系……它必须解析所有的Spring文件才能有效。
