想改善这个问题吗？更新问题，使其仅关注editing this post的一个问题。
5年前关闭。
Improve this question
我想知道之间的主要区别有哪些:
我知道@SessionScoped和@Stateful允许为每个客户端创建一个新实例。我也知道对于@ApplicationScoped和@Singleton/@Stateless，它们在客户端之间共享。
=>但是何时应该考虑，选择一个EJB或其他更好呢？
最佳答案
@SessionScoped表示作用域，而@Stateful是我们现在称为构造型的一种方式。 @Stateful向bean添加了一项服务，其中包括事务行为和钝化。
但是，@Stateful的核心是其 session 行为，它的确与 session 范围重叠。
区别在于， session 范围绑定(bind)到HTTP session ，而@Stateful是开放式用户管理的 session ，其生存期由引用Bean代理的客户端管理。@Stateful远程bean，最初是Servlet的二进制(RMI)计数器部分。 Servlet侦听来自浏览器的远程HTTP请求，而@Stateful远程bean侦听来自Applet(以及后来的Swing客户端)的远程RMI请求。
不幸的是，两者之间存在许多不一致之处。 Servlet只是一个HTTP侦听器，而@Stateful bean自动引入了许多其他功能。一个Servlet还与所有其他Servlet共享 session ，并在 war 中与所有其他Servlet共享Java EE组件 namespace ，而对于@Stateful EJB，每个单独的bean都有其自己的 session 和组件 namespace 。
随着EJB 2中引入本地bean以及用于远程EJB通信的Swing/Applet客户端的急剧减少，为@Stateful bean维护的 session 功能变得越来越不清楚。
我认为可以公平地说，@Stateful最近很少被使用。对于Web应用程序，HTTP session 几乎总是处于领先地位，这意味着将 session 范围和本地@Stateless bean和/或CDI bean用于业务逻辑。
在某些情况下，需要@Stateful bean来自然支持JPA的扩展持久性上下文及其钝化功能(Servlet没有标准化的钝化机制)。注意@Stateful和@SessionScoped(或许多其他范围)可以组合。合并它们的好处是用户代码不再需要管理生存期，而是由容器来管理它。@ApplicationScoped和@Singleton有一个相似的故事，尽管没有遗留问题(@Singleton是相当新的东西)。 @ApplicationScoped只是一个作用域，而@Singleton是一个bean类型(如果需要，可以是定型)，它不仅为您提供应用程序范围的行为，而且还为您提供了具有自动锁定功能(可以通过@Lock进行调整)的事务行为。并具有渴望的构造行为(通过@Startup)。
尽管@Stateful和@Singleton本身很方便，但Java EE的当前发展方向似乎是将这些内置构造型分解为可单独使用的注释，并且谁知道，也许有一天它们将是由这些分解后的注释组成的实际CDI构造型。