豆子，豆子，还有更多的豆子……什么做什么？

Question

我最近接到了一个涉及编写 Web 应用程序的项目。我以前从未做过 Java EE。网络上的很多资源都过时了，我无法弄清楚各种标准和 Java 技术之间的当前差异是什么。

由于依赖注入、JPA、会话管理和 Web 服务，最初我认为我真的需要 EJB 3.1。我开始尝试 Glassfish，但被告知我们必须在 Tomcat 中编写。所以我一直试图弄清楚我需要什么以及如何将什么以及如何放入 Tomcat 中才能到达那里。我已经开始怀疑我是否需要 EJB。

我想，我想将 JFS 用于 MVC 架构。在了解这一点时，我遇到了 ManagedBeans 和 CDI，根据一些人的说法，这使得前者已经过时，而且似乎还提供了我想要启用单元测试的所有依赖注入东西。我也开始意识到我可以在 EJB 之外以 Hibernate 和其他一些形式获得 JPA。此外，我不知道我是否需要的网络服务似乎以另一种我现在想不出名字的标准的形式出现，而且这也可以独立安装。

我的主要问题是会话管理和状态。在我看来，EJB 剩下要做的就是提供@Stateless/@Stateful 和@Local/@Remote。但是，据我了解，其中一些已经以 servlet 容器中的会话管理的形式存在......但我不知道我需要考虑多少或主要差异才能做出决定如果我需要这些东西。

所以我的问题是，为了决定 EJB 是否值得研究，或者我是否有足够的其他库和技术的形式，我需要了解哪些基本的、本质的区别？我已经在 google 和 Usenet 上搜索过，但在任何地方都找不到这些信息。

---

刚刚又想到了一点。据我了解，@Stateful bean 注释为我提供了线程安全的状态保存。我可能不会直接使用线程，但我知道 Java 经常在幕后这样做，尤其怀疑 EE。当我需要保持状态时，如果已经提供了线程，我不想处理线程。

Answer 1

ManagedBean

Java EE 6 有三种不同的方式来定义 beans，它们分别是 managed：

@javax.faces.bean.ManagedBean

JSF 2.0 引入了这个注解，在 faces-config.xml 中声明托管 bean。此注解用于从表达式语言访问 bean。

@javax.inject.Named

在 EE 6 容器 CDI 中，此注解是内置限定符类型，用于为 bean 提供名称，使其可以通过 EL 访问。

@javax.annotation.ManagedBean

这个注解试图概括 JSF 托管的 bean，以便在 Java EE 的其他地方使用。

如果您在 EE 6 容器中部署（如果您使用 Tomcat 或其他 servlet 容器，您还可以通过将 Weld jar 添加到您的 Web 应用程序来获取 CDI），那么确实没有理由使用 @javax.faces.bean.ManagedBean。只需使用 @javax.inject.Named 并开始利用 CDI 服务。

CDI

CDI 规范的目标之一是将 Web 层和事务服务结合在一起，使开发人员可以轻松地在 Java EE 平台的 Web 应用程序中使用 EJB 和 JSF。 使用 CDI，您可以获得以下服务：明确定义的生命周期 contexts（受接缝 2 和会话范围的影响）、Dependency injection、松散耦合设施，如 interceptors、decorators 和 events 以及可移植扩展，它允许第三方框架集成到 Java EE 6 环境中，例如 SEAM 3 extensions

托管 bean 和 EJB 服务

首先，CDI 适用于任何托管 bean。一些托管 bean 是 EJB。当我们需要在托管 bean 中使用 EJB 服务时，我们只需添加 @Stateless、@Stateful 或 @Singleton 注释即可。 IMO 它们充当补充技术，使您只需添加一些注释即可进行灵活和渐进的开发。

那么，我们什么时候应该使用会话 bean 而不是普通的托管 bean？

当您需要一些 CDI 缺少的 EJB 功能时：声明性事务、并发管理、池、远程或 Web 服务调用、计时器和异步方法调用。

当然，您也可以使用第三方库获得所有方面的信息 - 但这会给您的项目带来额外的复杂性。就功能而言，恕我直言 EJB 是实现的地方：

• 业务逻辑，允许您将业务逻辑和 Web 层逻辑完全分离（由“JSF 支持 bean”实现，它是 CDI 管理的 bean，但没有 EJB）
• 对于作为应用程序入口点的组件（通过 RMI 或 HTTP 交付的远程调用的端点）最有意义的功能

最后，如果您需要 EJB 服务，那么您需要一个 Aplication Server（例如 GlassFish 或 Jboss AS），如果您只需要 CDI 服务，您需要一个 Servlet 容器（例如 Tomcat）和 CDI 库。

Answer 2

您是否需要 EJB 提供的功能，例如安全性和事务管理？如果答案是肯定的，那么 EJB 可能是一个不错的选择。 如果答案是否定的，并且您只需要依赖注入，那么 CDI 可能是一个不错的选择。 您还可以使用其他 3rd 方产品获得类似的功能，例如 Spring（依赖注入、Spring 安全等），但在许多情况下，决定您是使用一个（EJB）还是另一个（例如 Spring）是以前的问题技能。

在我看来，如果没有以前的限制，那么符合 Java 规范是一项不错的投资。

Answer 3

我建议您从 CDI 开始，然后继续使用 EJB（实际上是在您的 POJO 之上添加一个注释），如果需求需要它们（正如它所告知的那样 - 事务性、Web 服务、JMX、计时器, EJB 异步调用）。

开发一个应用程序是非常合理的，其中您的入口点是一个 EJB，它包含您在事务中的调用并允许您定义多个入口点。然后，EJB 调用其中包含业务逻辑的 CDI bean。

还值得注意的是，TomEE 是在 Apache Tomcat 之上开发的经过认证的 Java EE 6 Web Profile。