为什么在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 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 Spring方式：

<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 将实例化需要实例化的所有内容。

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.

仍然不清楚更多的是什么

"still not clear on what the more is"

以下是一些优点：

1. Looser coupling


2. 更容易测试


3. 更好的分层


4. 基于界面的设计


5. 动态代理（segue to AOP）。

1. Looser coupling
2. Easier testing
3. Better layering
4. Interface-based design
5. Dynamic proxies (segue to AOP).

这篇关于为什么在Java EE中使用CDI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！