Question

我是Java EE的新手，我想知道使用CDI的真正好处是什么（@Named，@ Inject）。当然我问谷歌。但我总是得到一般的答案，如＆＃34;松耦合＆＃34;并且＆＃34;更好地测试＆＃34;。但我认为松散耦合不需要框架。

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

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的真正好处？

问候赫尔姆森

Answer 1

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

@Inject
@AnotherUser
private User user;

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

Answer 2

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

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

Java EE CDI的真正好处

2 个答案: