JavaEECDI的真正好处

我是JavaEE新手，我想知道使用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和change的另一个实现

UserIf user = new User();

到

我不认为在这里使用CDI有什么好处。当我想到由一些EJB和WAR组成的更大的EAR项目时，如果某些模块（EJB、WAR）是松耦合的，那么重用它们可能更容易。但据我所知，如果类不在同一个jar/war中，就不可能使用CDI。那么，使用CDI的真正好处是什么呢

---

Helmsen

重点是，如果您需要重命名另一个用户impl，或者您想要切换到其他实现，那么您必须转到使用此impl的所有类并重命名它。使用CDI限定符，您可以在任何地方使用

@Inject
@AnotherUser
private User user;

---

客户机代码对

用户的实现一无所知，所以您可以在业务端随意更改它，客户甚至不会注意到。松散耦合的原理是，使用API的客户机并不真正了解实现，这是在外部配置的（想想CDI生产者或SpringXML配置）。CDI还有其他好处，如生产者、拦截器、新的事务API、替代品或其他。
我真诚地认为，这只是一个非建设性的/操作性的结论。但是有一些事实可以帮助你更好地理解

CDI确实可以在一个耳朵中跨越罐子和战争。这个问题与
@ApplicationScoped
的定义有关，在EAR中，每个EJB-JAR模块和WAR模块在技术上都定义为它们自己的应用程序

您要问的问题更多的是什么是依赖注入/控制反转，而不是具体的CDI。不是每个人都想使用这些范例，但实际上它们是规范

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

@Inject
@AnotherUser
private User user;