@SessionScoped (CDI)和@Stateful (Java EE)之间的差异

Question

我了解到CDI Beans可以在不同的基于web应用程序的作用域中使用(只在那里，对吗？)。例如：@RequestScoped、@SessionScoped等等。@SessionScoped在整个浏览器会话中将数据保存在托管bean中。从逻辑上讲，这听起来很安静，因为注释名称描述了它所做的事情。然而，现在我对EJB会话bean有了更深入的了解。到目前为止，我知道这样的of可能有三种状态之一：@Stateless，@Stateful和@Singleton。对我来说，这些注释与CDI bean的注释有直接的可比性：@RequestScoped --> @Stateless，@SessionScoped --> @Stateful，@ApplicationScoped --> @Singleton。但由于我正在研究一些示例，我发现了一个同时包含@Stateful和@SessionScoped注释的bean。我寻找一个解释--但我没有找到任何可以理解的答案。那么，到底有什么不同呢？为什么我必须同时使用两个注释？谢谢。

Answer 1

CDI Beans可以在不同的基于web应用程序的作用域中使用(只在那里，对吧？)

不对。CDI bean可以用在你想要的任何地方- DB连接/通信，业务逻辑，甚至在Java SE中基于事件的编程(Weld，CDI的参考实现，甚至现在也提供了这一点)。但是，具体地说，HTTP在@SessionScoped会话中比在其他任何地方更有意义。但是，您仍然可以将会话想象(并使用)为具有标记开始和结束的给定时间段。在这些范围内，会话是存在的-不需要是HTTP会话，但它是最明显的一个。

它们与CDI bean的注释之间的直接可比性：@RequestScoped --> @Stateless，@SessionScoped --> @Stateful，@ApplicationScoped --> @

。

又错了。EJB只链接到web通信，而CDI不是。同样，根据您选择的注解，您还可以选择一个容器(CDI/EJB)，它将负责该bean。CDI集成了所有EJB bean (创建代理并使其“看起来”像是CDI bean-允许您在EJB bean中使用CDI内容)。

例如，@Stateless在CDi/Weld中内部表示为@Dependent作用域，而不是@RequestScoped，因为@Stateless中的EJB bean是重用的，您无法真正了解它们的状态。在CDI中使用@RequestScoped时，您将激活请求上下文(让我们坚持使用HTTP，因此通过发送某些东西来激活它)，这将触发所有@RequestScoped bean的创建。在请求之后，所有这些bean都被销毁了，再也不会被使用。因此，您可以完全依赖于您放入的内容，并且还可以确保它在请求之后不会存活。

另一个故事是@ApplicationScoped与@Singleton的较量。这些确实非常相似，最重要的细节可能是CDI创建了自己的bean代理。但对于这个问题来说，这太详细了，我认为你现在可以认为它们是可比较的。

@SessionScoped (CDI)和@Stateful (Java )之间的

差异

现在，最后谈一谈原来的问题。我认为，要在总体上理解这些差异，您需要了解CDI在contexts上操作的事实。它总是激活上下文(在本例中为会话上下文)，这时会出现一组@SessionScoped beans，您可以与它们通信，它们具有值和状态等。上下文相互交错，因此在同一时间内，请求上下文可能存在，而应用上下文确实存在。因此，我们可以说，@SessionScoped绑定到会话并由容器控制，而@Stateful为您提供了一个用户管理的会话，其生命周期由客户端管理，它还在此基础上添加了许多其他功能。

您有时可以在一个bean上看到两个注释的原因是，人们将它们组合在一起以获得两个世界的最佳效果-容器管理的生命周期和添加的功能。但请注意，虽然现在@Stateful使用得不多(选择使用@Stateless通常更有意义)，但@SessionScope更加通用，几乎适用于任何基于会话的场景。

希望它至少能提供一些启发，我担心这是一个非常复杂的话题。

Answer 2

EJB Beans默认为您提供事务，而CDI Beans不提供。

我想这就是不同之处