Java EE CDI 的真正好处是什么？

Question

我刚接触Java EE，想知道使用CDI（@Named，@Inject）的真正好处。当然我问过谷歌，但总是得到一些笼统的回答，如“松耦合”和“更易测试”。但我认为不需要框架就能实现松耦合。

在我的小项目中，我使用了三个类。

public interface UserIf
{
    ...
}

@Named
public class User implements UserIf
{
     ...
}

public class Main
{
    @Inject
    UserIf user;
}

现在我可以轻松地注入另一种UserIf实现。但是我也可以使用

public class Main
{
    UserIf user = new User();
}

这种架构也很容易更改。只需编写另一个UserIf实现并更改即可。

UserIf user = new User();

to

UserIf user = new AnotherUserImpl();

我认为在这里使用CDI没有好处。当我考虑一个由一些EJB和WAR组成的更大的EAR项目时，如果它们是松散耦合的，可能更容易重用一些模块（EJB，WAR）。但据我所知，如果类不在同一个jar / war中，则无法使用CDI。那么什么样的设置才能真正获得使用CDI的实际好处呢？

问候 Helmsen

- user3909622

Answer 1

重点在于，如果您需要重命名AnotherUserImpl或者想要切换到其他实现方式，那么您必须去修改使用此实现方式的所有类的名称。但是，使用CDI限定符，您可以在所有地方进行更改。

@Inject
@AnotherUser
private User user;

客户端代码不知道User的实现方式，因此您可以在业务端自由更改它，而客户端甚至不会注意到。松耦合原则是，使用您的API的客户端实际上并不知道其实现方式，这是通过外部配置完成的（考虑CDI Producers或Spring XML配置）。 CDI还有其他好处，例如Producers、Interceptors、新的Transaction API、Alternatives或其他。

- Petr Mensik

Answer 2

说实话，我正在考虑将其标记为非建设性/主观的关闭。但是有一些事实可以帮助您更好地理解。

1. CDI确实可以跨JAR和WAR在EAR中工作。问题与@ApplicationScoped的定义有关，在EAR中，每个EJB-JAR模块和WAR模块在技术上被定义为它们自己的应用程序。

2. 您正在问的类型问题更多关于什么是依赖注入/控制反转而不是特定于CDI。并非每个人都想使用这些范例，但实际上它们是规范。

3. 内置的作用域模型允许您更加声明性地管理何时创建实例，而不是以编程方式。在CDI中，将作用域应用于bean是一种注释。然后该bean变得可以随时供您使用。

- John Ament