为什么在Java EE中使用CDI

Question

我知道有很多文章可以解释如何在Java EE中使用CDI，但是我很难弄清楚这实际上带来了什么好处。例如，假设我有一个当前使用Foo实例的类。我可能会做

Foo myFoo = new Foo();

要么

// Better, FooFactory might return a mock object for testing    
Foo myFoo = FooFactory.getFoo();

我一直在阅读CDI，我可以做到：

@Inject
Foo myFoo;

但是为什么这比以前的基于工厂的方法更好呢？我认为还有一些我不知道的用例，但我无法识别。

如果我理解下面的响应，则概念是DI框架充当集中配置的主对象工厂。这是合理的解释吗？

更新资料

从那时起，我就开始学习Spring，这现在变得更加有意义。以下段落摘自 Spring in Practice，
以一个AccountService类的示例为例，而该类又使用的实例AccountDao。对于长报价我深表歉意，但我认为这确实使为什么注入的资源能够提供一些超出标准初始化的东西很重要。

您可以使用new关键字构造AccountService，但是创建服务层对象很少那么简单。
它们通常取决于DAO，邮件发件人，SOAP代理等等。您可以在AccountService构造函数中以编程方式实例化每个依赖项（或通过静态初始化），但是这会导致硬性依赖关系和级联更改，因为它们被换出了。

此外，您可以在外部创建依赖项，并通过setter方法或构造函数参数在AccountService上进行设置。
这样做将消除硬的内部依赖关系（只要它们在AccountService中通过接口声明即可），但是您到处都有重复的初始化代码。这是创建DAO并将其以Spring方式连接到AccountService的方法：

<bean id="accountDao" class="com.springinpractice.ch01.dao.jdbc.JdbcAccountDao"/>

<bean id="accountService"
    class="com.springinpractice.ch01.service.AccountService">
    <property name="accountDao" ref="accountDao"/>
</bean>

如上所述配置了bean之后，您的程序现在可以AccountService从Spring ApplicationContext
请求的实例，并且Spring DI框架将在实例化之后进行所有需要实例化的工作。

Answer 1

编写CDI的人给了您一个大对象工厂。他们为您做的工作比您做的更好。它是XML配置或注释驱动的，因此您不必将所有内容都嵌入代码中。

像Spring这样的依赖注入引擎比您的工厂做得多。要复制它们提供的所有内容，将需要多个工厂类和一行代码。

当然，您不必使用它。您始终可以自由发明自己的车轮。而且，您应该-
如果您的目的是学习如何制作轮子或消除依赖关系。

但是，如果您只想开发应用程序，则最好使用其他人为您带来优势时提供的工具。

关于依赖注入的开创性文章由Martin
Fowler撰写。我建议阅读它；八年后，它仍然很棒。

“还不清楚什么是更多”

这里有一些优点：

1. 松耦合
2. 更容易的测试
3. 更好的分层
4. 基于界面的设计
5. 动态代理（针对AOP）。