我知道有很多文章可以解释如何在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并将其连接的方法
以春季的方式取决于您的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之后，您的程序现在可以从Spring ApplicationContext请求
AccountService的实例，并且Spring DI框架将在实例化之后实例化所有需要实例化的内容。 最佳答案
编写CDI的人给了您一个大对象工厂。他们为您做的工作比您做的更好。它是XML配置或注释驱动的，因此您不必将所有内容都嵌入代码中。
像Spring这样的依赖注入引擎比您的工厂做得多。要复制它们提供的所有内容，将需要多个工厂类和一行代码。
当然，您不必使用它。您始终可以自由发明自己的车轮。而且您应该-if your purpose is to learn how to make wheels或消除依赖性。
但是，如果您只想开发应用程序，则最好使用其他人为您带来优势时提供的工具。
关于依赖项注入的seminal article由Martin Fowler撰写。我建议阅读它；八年后，它仍然很棒。
“还不清楚什么是更多”
这里有一些优点：
松耦合
轻松测试
更好的分层
基于界面的设计
动态代理（针对AOP）。