@SessionScoped（CDI）和@Stateful（JavaEE）之间的差异

Question

我了解到CDI Beans可以在不同的基于Web应用程序的作用域中使用（只有在那里，对吗？）。例如：@quiestScoped、@SessionScoped等等。@SessionScoped在整个浏览器会话中保存托管bean中的数据。这在逻辑上听起来很安静，因为注释名称描述了它的功能。然而-现在我仔细查看了EJB会话bean。到目前为止，我知道这样一个人可能有三种状态之一：无国籍、有州和单身。对我来说，这些和CDI bean的注释之间似乎有直接的可比性：@请求范围-

Answer 1

ejbbean默认为您提供事务，cdibean不提供。

我想这就是区别

Answer 2

CDIBeans可以在不同的基于web应用程序的范围内使用（只有在那里，对吗？）。

错误的CDIBeans可以在您想要的任何地方使用—DB连接/通信、业务逻辑、甚至在JavaSE中基于事件的编程（Weld，CDI的参考实现，现在就提供了这一点）。然而，特别是@SessionScopedbean在HTTP会话中比在其他任何地方都更有意义。但您仍然可以将会话想象（并使用）为一个给定的时间段，带有标记的开始和结束。在这些界限内，会话是存在的——不需要是HTTP会话，但它是最明显的。

这些与CDIBean注释之间的直接可比性：@RequestScoped--

又错了。EJB只链接到网络通信，CDI没有。同样基于您选择的注释，您还可以选择一个容器（CDI/EJB）来负责该bean。CDI集成了所有EJB bean（创建一个代理，并使其“看起来”像一个CDI bean——允许您在EJB bean中使用CDI东西）。

例如，在CDi/Weld中，@Statless在内部表示为@依赖的范围，而不是@ResestScoped，因为EJB中的@Statlessbean被重新使用，并且您无法真正了解它们是什么状态。当在CDI中使用@quiestScoped时，您将激活请求上下文（让我们坚持使用HTTP，因此通过发送内容来激活它），这将触发所有@quiestScopedbean的创建。请求后，所有这些豆子都被销毁，再也不用了。所以你可以完全依赖你放在里面的东西，你也可以确保它在请求后不会存活。

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

@SessionScoped（CDI）和@Stateful（JavaEE）之间的差异

现在最后回到最初的问题。我认为要理解这些差异，你需要理解CDI在上下文中运行的事实。它总是激活上下文（在这种情况下是会话上下文），这时一组@SessionScopedbean出现了，你可以与它们通信，它们有值和状态等。上下文插入，因此在同一时间，请求上下文可能存在，应用上下文肯定存在。所以我们可以说，@SessionScoped绑定到会话，并由容器控制，而@Stating为您提供了一个用户管理的会话，其生存期由客户端管理，并且它还在顶部添加了许多其他功能的那个。

您有时可以在一个bean上看到两个注释的原因是人们将它们结合起来以获得两个世界的最佳效果——容器管理的html" target="_blank">生命周期和添加的功能。但是请注意，虽然这些天很少使用@Stable（通常选择加入@无状态更有意义），但@SessionScope更加通用，几乎适合任何基于会话的场景。

希望它至少能有所启发，恐怕这是一个非常复杂的话题。