@SessionScoped（CDI）和@Stateful（Java EE）之间的区别
我了解到，CDI Beans可以用于不同的基于Web应用程序的范围（仅在那里，对吗？）。 例如：@RequestScoped，@SessionScoped等。 @SessionScoped通过完整的浏览器会话将数据保存在托管bean中。 这听起来很安静，因为注释名称描述了它的功能。 但是 - 现在我仔细看看EJB会话bean。 到目前为止，我知道，这样的一个人可以拥有三种状态之一：@Stateless，@Stateful和@Singleton。 对我来说，看起来它们和CDI bean的注释之间有直接的可比性：@RequestScoped - > @Stateless，@SessionScoped - > @Stateful，@ApplicationScoped - > @Singleton。 但是自从我研究了一些例子，我发现了一个包含@Stateful和@SessionScoped注解的bean。 我寻找一个解释 - 但我没有找到任何可以理解的答案。 那么，究竟有什么不同？ 为什么我必须使用两个注释？ 谢谢。
默认情况下EJB Bean是交易，CDI Beans不。
我认为这是不同的
CDI Beans可以用于不同的基于Web应用程序的范围（仅在那里，对吗？）。
错误。 CDI bean可以用在任何你想要的地方 - 数据库连接/通信，商业逻辑，甚至在Java SE中的基于事件的编程（Weld，CDI的参考实现，甚至现在也提供这个）。 但是，特别是@SessionScoped bean在HTTP会话中比其他任何地方更有意义。 但是你仍然可以想象（并使用）会话作为给定的时间段，并标记开始和结束。 在这些边界内，会话存在 - 不需要是HTTP会话，但它是最明显的会话。
它们和CDI bean的注释之间的直接可比性：@RequestScoped - > @Stateless，@SessionScoped - > @Stateful，@ApplicationScoped - > @Singleton。
又错了。 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 EE）之间的区别
现在终于到了原来的问题。 我认为，为了把握这些差异，你需要了解CDI在上下文中运作的事实。 它总是激活上下文（在这种情况下是会话上下文），并且在那一刻有一组@SessionScoped bean存在，并且你可以与它们进行通信，并且它们具有值和状态等等。上下文在一个请求上下文存在和应用上下文确实存在。 所以我们可以说@SessionScoped绑定到会话并由容器控制，而@Stateful为您提供一个用户管理的会话，其生命周期由客户端管理，而且它还增加了许多其他功能。
有时你可以在一个bean上看到两个注释的原因是人们将它们结合起来，以获得两全其美的效果 - 容器管理的生命周期和增加的功能。 但请注意，尽管@Stateful现在用得不多（通常选择加入@Stateless更有意义）， @SessionScope更具普遍性，几乎适用于任何基于会话的场景。
希望它至少有一些亮光，这是一个非常复杂的话题。
链接地址: http://www.djcxy.com/p/62217.html上一篇: Diff between @SessionScoped (CDI) and @Stateful (Java EE)