依赖注入成瘾?

依赖注入成瘾?

Dependency Injection Addiction?

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

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

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

有什么想法吗? 不好的经历? 还是别再担心了?

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

很抱歉含糊。 马丁·福勒(Martin Fowler)可能比我以前更好地描述了FAR ...无需浪费精力。

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


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


DI的问题与COM以及任何类似以下代码的问题相同:

1
i = GetServiceOrInterfaceOrObject(...)

问题是无法从代码中理解这样的系统。 [else]某处必须有文档定义服务/接口/对象X可以请求哪些服务/接口/对象。该文档不仅必须维护,而且必须像源一样容易获得。

除非文档写得很好,否则通常很难看到对象之间的关系。有时关系是暂时的,这使得它们更难被发现。

我喜欢KISS原则,并且坚信使用正确的工具来完成工作。如果对于给定的项目,DI的好处胜于编写可理解的代码,而不是使用它。


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

仅供参考,作为JDK 6的一部分,有一个非常简单且功能强大的依赖注入。如果您需要轻量级,直接的依赖注入,请使用它。

使用ServiceLoader类,您可以基于类请求服务(或该服务的许多实现):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 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

这尚未广为人知。


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


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


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

在我看来,DI似乎更适合大型,复杂的系统-对于小型一次性应用程序,它可能会导致应用程序架构过重,从根本上讲,架构需要花更多的开发时间才能完成。可以弥补其提供的价值。


对于我们当中那些在家里玩的人,您能否添加一个或两个链接来解释什么是依赖注入?维基百科的文章很有趣,但是却不是很有启发性。


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


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


推荐阅读