Java EE CDI的真正好处

我是Java EE的新手，我想知道使用CDI (@Named， @Inject)的真正好处是什么。我当然是在问谷歌。但我总是得到一般的答案，比如"松耦合"one_answers"更好地测试"。但是我认为要实现松耦合，不需要任何框架。

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

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的真正好处是什么呢?

问候Helmsen

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

随处可见

@Inject
@AnotherUser
private User user;

客户端代码不知道任何关于User的实现，所以你可以自由地在业务端改变它，客户端甚至不会注意到。松耦合的原则是使用API的客户端并不真正了解实现，这是外部配置的(想想CDI生产者或Spring XML配置)。CDI还有其他的好处，比如生产者、拦截器、新的事务API、替代品等等。

老实说，我只是把它当作非建设性的/固执己见的。但是有一些事实可以帮助你更好地理解。

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

相关内容