为什么在 Java EE 中使用 CDI
我知道有很多文章解释了如何在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 in Practice,以一个类为例,该类又使用 .我很抱歉这个长引号,但我认为它确实触及了为什么注入的资源提供了一些超过标准初始化的东西的核心。AccountService
AccountDao
您可以使用 new 关键字构造帐户服务,但服务层对象的创建很少如此简单。它们通常依赖于 DAO、邮件发件人、SOAP 代理等等。您可以在 AccountService 构造函数中以编程方式实例化每个依赖项(或通过静态初始化),但这会导致硬依赖项和级联更改在换出时。
此外,还可以在外部创建依赖项,并通过 setter 方法或构造函数参数在 AccountService 上设置它们。这样做可以消除硬的内部依赖关系(只要它们是通过接口在帐户服务中声明的),但是您将在任何地方重复初始化代码。以下是如何创建 DAO 并将其连接到您的帐户服务:
<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请求一个实例,Spring DI框架将负责实例化需要实例化的所有内容。AccountService