Java EE CDI 的真正好处答案

【问题标题】：Real benefits of Java EE CDIJava EE CDI 的真正好处
【发布时间】：2014-08-05 10:03:13
【问题描述】：

我是 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();

到

UserIf user = new AnotherUserImpl();

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

问候赫尔姆森

【问题讨论】：

标签： java dependency-injection cdi

【解决方案1】：

关键是，如果您需要例如重命名AnotherUserImpl，或者您想切换到其他实现，那么您必须转到所有使用此实现的类并重命名它。使用 CDI 限定符，您无处不在

@Inject
@AnotherUser
private User user;

客户端代码对User 的实现一无所知，因此您可以在业务方面随意更改它，而客户端甚至不会注意到。松耦合的原则是使用您的 API 的客户端并不真正了解实现，这是外部配置的（想想 CDI 生产者或 Spring XML 配置）。 CDI 还有其他好处，例如生产者、拦截器、新的事务 API、替代方案或其他。

【讨论】：

【解决方案2】：

老实说，我只是将其关闭为非建设性/固执己见。但是有一些事实可以帮助您更好地理解。

CDI 确实可以跨 EAR 中的 JAR 和 WAR 工作。问题与@ApplicationScoped 的定义有关，在 EAR 中，每个 EJB-JAR 模块和 WAR 模块在技术上都定义为它们自己的应用程序。
您要问的问题类型更多的是关于什么是依赖注入/控制反转，而不是具体的 CDI。不是每个人都想使用这些范式，但实际上它们是规范。
内置的作用域模型允许您以声明方式而不是编程方式来管理创建实例的时间。在 CDI 中，将作用域应用于 bean 是一种注释。然后该 bean 就可以随时供您使用了。

【讨论】：