有不利的一面吗？我现在感觉几乎依赖它了。每当项目超过一定规模时，几乎都会对标准模式产生过敏反应，并立即使用依赖注入框架重新连接它。
我发现的最大问题是它可能会让其他刚刚学习它的开发人员感到困惑。
另外，如果它是我使用的语言的一部分，我会感觉好多了。不过，至少对于 Java，有几个非常轻量级的库非常好。
想法？糟糕的经历？或者只是停止担心它？
[编辑] 回复：依赖注入本身的描述
抱歉含糊其辞。Martin Fowler对它的描述可能比我以往任何时候都好……无需浪费精力。
巧合的是，这证实了一点，即它仍然没有得到广泛的实践，如果每个人都没有跟上进度，在与团队合作时可能会成为障碍。
我在博客文章中描述了一些可能的缺点：http: //kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html
DI 遇到的问题与 COM 和任何看起来类似的代码的问题相同：
i = GetServiceOrInterfaceOrObject(...)
问题是这样的系统无法从代码中理解。[其他] 必须有文档定义服务/接口/对象 X 可以请求哪些服务/接口/对象。该文档不仅必须维护，而且与源一样容易获得。
除非文档写得很好，否则通常仍然不容易看到对象之间的关系。有时关系是暂时的，这使得它们更难被发现。
我喜欢 KISS 原则，并且我坚信使用正确的工具来完成这项工作。如果对于给定项目，DI 的好处超过了编写可理解代码的需要，而不是使用它。
我是 IO 中的大盲人，但是我看到一些项目带有巨大的 xml 配置文件，没人理解。所以要小心使用 xml 编程。
另外，如果它是我使用的语言的一部分，我会感觉好多了。
仅供参考，作为 JDK 6 的一部分，有一个非常简单且功能强大的依赖注入。如果您需要轻量级、直接的依赖注入，请使用它。
使用ServiceLoader类，您可以基于类请求服务（或服务的许多实现）：
package dependecyinjection;
import java.util.ServiceLoader;
public abstract class FooService {
public static FooService getService() {
ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);
for (FooService service : loader) {
return provider;
}
throw new Exception ("No service");
}
public abstract int fooOperation();
}
package dependecyinjection;
public class FooImpl extends FooService {
@Override
public int fooOperation() {
return 2;
}
}
ServiceLoader 如何定义返回的服务实现？
在您的项目文件夹中创建一个名为META-INF/services的文件夹并创建一个名为dependencyinjection.FooService的文件。此文件包含指向服务实现的行。在这种情况下：dependecyinjection.FooImpl
这还不是广为人知。
在我看来，主要缺点是学习曲线（正如您所指出的）和增加抽象的潜力，使其更难调试（这也是学习曲线的一部分）。
对我来说，DI 似乎更适合大型、复杂的系统——对于小型一次性应用程序，它可能导致应用程序过度架构，基本上，让架构花费更多的开发时间来坚持可以弥补它提供的价值。
别担心了。我认为，随着时间的推移，IoC 技术将成为大多数开发人员的第二天性。我正试图在工作中教开发人员，但我发现很难传达信息，因为这对我们一直做事的方式感觉太不自然了……这恰好是错误的方式。此外，对于 IoC 的新手和我发现的项目的新手来说，开发人员的日子会更加艰难。他们习惯于使用 IDE 跟踪依赖关系，以了解整个事物是如何“挂在一起”的。该信息通常被写入神秘的 XML。
对于我们这些在家玩的人，您能否添加一两个链接来解释依赖注入实际上是什么？维基百科的文章很有趣，但不是很有启发性。
我能想到的唯一缺点是通过不断的虚拟调用导致性能下降:)
@Blorgbeard： http: //www.martinfowler.com/articles/injection.html可能是关于该主题的最佳文章之一