0

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

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

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

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

所以我的问题是，为了决定 EJB 是否值得研究，或者我是否有足够的其他库和技术的形式，我需要知道哪些基本的、本质的区别？我一直在谷歌和 Usenet 上，但无法在任何地方找到这些信息。

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

4

3 回答 3

3

托管豆

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（受 seam 2 和会话范围的影响），Dependency injection松散耦合设施，如拦截器、装饰器和事件以及可移植扩展，允许第三方框架集成到 Java EE 6 环境，如SEAM 3 扩展

托管 bean 和 EJB 服务

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

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

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

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

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

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

于 2011-09-24T15:18:25.590 回答
1

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

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

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

于 2011-10-08T13:31:27.427 回答
1

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

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

于 2011-09-22T23:13:51.507 回答