有不利的一面吗？我现在几乎要依赖它了。每当项目超过一定大小时，几乎都会对标准模式产生过敏反应，并立即使用Dependency Injection框架将其重新连接。

我发现的最大问题是，其他正在学习它的开发人员可能会感到困惑。

另外，如果它是我所使用的语言的一部分，我会感觉好多了。但是，至少对于Java而言，有几个非常轻量的库，它们非常好。

有什么想法吗？不好的经历？还是不再担心它？

[编辑]回复：依赖注入本身的描述

抱歉，内容含糊。马丁·福勒(Martin Fowler)可能比我以前描述的要好得多……无需浪费精​​力。

巧合的是，这证实了这一点，即它仍未得到广泛实践，并且如果每个人都不能跟上它的步伐，则在与团队合作时可能会成为障碍。

解决方案

回答

我唯一能想到的缺点是通过不断的虚拟调用会导致性能的微小下降:)

回答

对于我们中的一些人，我们能否添加一个或者两个链接来说明什么是依赖注入？维基百科的文章很有趣，但是却不是很有启发性。

回答

我在这里的博客文章中描述了一些可能的弊端：http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

回答

在我看来，主要缺点是学习曲线(如我们所指出的那样)以及增加抽象的可能性，使抽象的调试更加困难(这实际上也是学习曲线的一部分)。

在我看来，DI似乎更适合大型，复杂的系统-对于小型一次性应用程序，它可能会导致应用程序架构过重，基本上，架构需要花更多的时间才能坚持下去。永远弥补它提供的价值。

回答

我是IO中的大砍刀，但是我看到一些带有巨大xml配置文件的项目，没人能理解。因此要当心xml编程。

回答

@Blorgbeard：http://www.martinfowler.com/articles/injection.html可能是该主题上最好的文章之一

回答

别再担心了。我认为，随着时间的流逝，IoC技术将成为大多数开发人员的第二天性。我试图在这里教开发人员有关此问题的信息，但我发现很难传达信息，因为它对我们一直做事的方式感到不自然。.恰巧这是错误的方式。而且，无论是IoC的新手还是我发现的新项目的开发人员都更加费劲。他们习惯于使用IDE来跟踪依赖关系，以了解整个过程是如何"组合在一起"的。该信息通常被写入神秘的XML中。

回答

Also, I'd feel much better if it were
  a part of the language I was using.

仅供参考，作为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

这尚未广为人知。