依赖注入框架:它们如何工作？

Question

我认为自己是一位经验丰富的程序员,并且理解依赖注入的基本概念.另一方面,我的大多数经验都是编写相对较低级别的单人数字运算代码.我没有任何从事大型企业项目的经验.

鉴于这种背景,我不能为我的生活包围我为什么有人需要一个框架来进行依赖注入.有人可以给我一个简短的概述这个框架是如何工作的,而不是涉及很多细节,并解释它如何使生活更轻松而不仅仅是滚动你自己？

编辑:我在这里得到了一些很棒的答案.我是否正确地说DI框架基本上为您提供了一种方便的方法来创建全局可访问的工厂,只要对象请求它们就会创建/返回依赖项实例？如果是这样,我一直在我的代码中以非常特殊的方式做这样的事情,但从未想过要使用任何形式的正式/重量级框架.

Answer 1

DI就是解耦类之间的依赖关系.

使用DI,您的类不再具有实现类的引用.工厂模式接近DI,但它是不同的,因为工厂类是自己的不必要的依赖(例如,这将伤害单元测试).

DI也不一定是全球或应用范围的事情; 可以为同一个应用程序和相同的类配置不同的依赖关系模式.甚至可以存在运行时依赖性.DI甚至可以确定对象需要生存的生命周期或范围(请求范围,会话范围等).

如果你看一下像谷歌的Guice这样的轻量级DI实现,它也不是重量级或侵入性的.他们称之为新的"新"并非毫无意义.

Answer 2

维基百科对福利和实施有很好的写作.

http://en.wikipedia.org/wiki/Inversion_of_control

我发现像Spring这样的IoC容器是有用的,因为它们所做的所有其他"东西",比如事务管理,以及它们提供的代码,比如代码模板,测试基类等,这些都是非常有用的.此外,在Java世界中,我认为IoC是对Java EE标准的反应,许多开发人员发现它太笨重了.IoC由Spring实现,它允许您设计POJO服务组件,在大多数情况下,我认为这比Java EE让人们跳过的箍更容易.

我很多,或者至少其中一些是精神手淫,在某种程度上,这意味着容器提供的IoC优势在大多数使用它们的项目中都没有得到充分利用.
"我们应该使用DI,因为我们将来能够轻松地交换我们DAO的实现,yippeeeeee" - 在我的经验中很少发生.人们使用它们是因为它们已成为标准,并且流行语恕我直言.我不是说这是坏事; 只是标准软件的IoC部分并不是它们使用的真正原因.