为什么在 Java EE 中使用 CDI [英] Why use CDI in Java EE
问题描述
我知道有很多文章解释了如何在 Java EE 中使用 CDI，但我无法弄清楚这实际上带来了什么优势.例如，假设我有一个当前使用 Foo 实例的类.我可能会这样做
I know there are a lot of articles out there that explain how to use CDI in Java EE but I'm having trouble figuring out what advantage this actually brings. For example, suppose I have a class that currently uses an instance of Foo. I might either do
Foo myFoo = new Foo();
或
// Better, FooFactory might return a mock object for testing
Foo myFoo = FooFactory.getFoo();
我一直在阅读我可以使用 CDI 做的事情:
I keep reading that with CDI I can do:
@Inject
Foo myFoo;
但是为什么这比以前基于工厂的方法更好?我假设还有一些我不知道的其他用例，但我无法确定这一点.
but why is this better than the previous factory based approach? I assume there is some other use case that I'm not aware of but I haven't been able to identify this.
如果我理解下面的回答，那么概念是 DI 框架充当集中配置的主对象工厂.这是一个合理的解释吗?
If I've understood the responses below, the concept is that the DI framework acts as a master object factory that is configured centrally. Is this a reasonable interpretation?
更新
我从那以后开始学习 Spring，现在这更有意义了.下面的段落取自Spring in Practice，以AccountService 类为例，该类又使用AccountDao 的一个实例.我为冗长的引用道歉，但我认为它确实触及了为什么注入的资源比标准初始化提供一些东西的核心.
I've since started learning Spring and this now makes a lot more sense. The paragraph below is taken from Spring in Practice taking an example of an AccountService class which in turn, uses an instance of AccountDao. I apologise for the long quote but I think it really gets to the heart of why injected resources offer something over standard initialisation.
您可以使用 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 框架将负责实例化所有需要实例化的内容.
Having configured the beans as above, your program can now request an instance of AccountService from the Spring ApplicationContext and the Spring DI framework will look after instantiated everything that needs instantiating.
推荐答案
编写 CDI 的人给了你一个大对象工厂；他们为您完成了工作，比您做得更好.它是 XML 配置或注释驱动的，因此您不必将所有内容都嵌入到代码中.
The people that wrote CDI gave you one big object factory; they did the work for you, better than you would. It's XML configuration or annotation driven, so you don't have to embed everything in code.
依赖注入引擎，比如 Spring，比你的工厂做的更多.复制它们提供的所有内容需要不止一个工厂类和一行代码.
Dependency injection engines, like Spring, do a lot more than your factory. It'll take more than one factory class and one line of code to duplicate all that they offer.
当然你不必使用它.你总是可以自由地发明你自己的轮子.您应该 - 如果您的目的是学习如何制作轮子或消除依赖性.
Of course you don't have to use it. You are always free to invent your own wheel. And you should - if your purpose is to learn how to make wheels or eliminate dependencies.
但如果您只想开发应用程序，最好使用其他人在给您带来优势时提供的工具.
But if you want to just develop applications, it's better to use the tools that others provide when they give you an advantage.
关于依赖项注入的开创性文章由 Martin Fowler 撰写.我建议阅读它；八年后，它仍然很棒.
The seminal article on dependency injection was written by Martin Fowler. I'd recommend reading it; it's still great, eight years later.
还不清楚更多是什么"
以下是一些优点:
- 松耦合
- 更轻松的测试
- 更好的分层
- 基于界面的设计
- 动态代理(转为 AOP).
这篇关于为什么在 Java EE 中使用 CDI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
