28

开始一个新项目，想知道在 WAR 和 EAR 中打包 EJB 的优缺点。

当 EJB 处于 WAR 中时，JNDI 是否仍然有效？效率？ETC。？

谢谢。

4

5 回答 5

58

将 EJB bean 放在单独的 JAR 中的一个重要动机是业务逻辑和视图逻辑的古老分离。

由于 EJB 应该只专注于业务逻辑，因此将它们放入单独的模块中是有意义的。

这正是传统 Java Enterprise Archive 所促进的。EJB bean 进入一个EJB module代表Web module. 请注意，WAR 实际上不一定是文件。在所谓的分解格式中，它们只是目录。

这种分离的一个关键方面是这两个模块通过类加载器层次结构隔离。可以从Web module中访问资源（通常是 bean）EJB module，并且EJB module可以引用在整个 EAR 保护伞中定义的资源（通常是库）。另一个方向是不可能的。具体来说，EJB module无法访问Web module.

这种强制执行是故意的。

业务逻辑应该完全独立于任何视图技术。强制执行这种隔离可以防止开发人员意外或在压力下混合这些问题。这种分离的好处是业务逻辑可以很容易地被 Java SE 客户端、Web 模块客户端、JAX-RS 客户端等使用。如果业务逻辑不小心有 JSF 或 Servlet 依赖项，则很难使用它来自 Java SE 客户端。

将此与 Facelets 不允许使用 scriptlet 进行比较。这使 Facelets 保持干净，让它们专注于组件布局和标记。另一个类比是对接口的编码，它将合同与实现分开。

所以拥有一个单独的 EJB 模块实际上是一种最佳实践。然而...

对于较小的项目，可能没有必要进行这种分离，而对于初学者来说，可能很难将他们的头脑围绕在需要去哪里的结构上。因此，取消强制分离使没有经验的开发人员更容易开始使用 Java EE。它为他们提供了对 Java EE 的温和介绍，然后一旦他们有了分层的想法，他们就可以选择引入EJB module无论如何。

于 2010-12-27T14:44:26.967 回答
6

到目前为止，这就是我得到的。

WAR 中的 EJB

优点：

  1. 更易于开发和部署

  2. 您可以使用 @Path 注释将会话 Bean 方法公开为 REST 服务。看这里

缺点：

  1. 不支持 JNDI 查找，所以我相信您不能从另一个应用程序客户端执行 RMI

  2. 正如 arjan 指出的那样，它在设计上缺乏模块化。

于 2010-12-28T21:57:24.337 回答
5

我认为您需要记住的是，WAR 中的 EJB 是 EJB Lite 的一部分，这是使应用程序以 EJB 容器提供的最少服务运行的一个很好的努力。因为您并不总是需要 EJB 容器提供的所有服务。

因此，如果您想知道将 EJB 打包到 WAR 或 EAR 中的利弊，那么您应该考虑一下您需要多少服务。

HTH。

于 2010-12-25T11:15:41.613 回答
5

我目前正在研究一些 EJB 3.1 认证指南，并且必须测试它的每个功能。并且在使用战争时都可以使用。

EJB Lite 与 WAR 打包非常不同。

您可以使用可以包含在 Web 项目中的 ejb jar 来获得一些逻辑模块化。但是所有模块共享相同的环境 (jndi)，因此可能会发生一些名称冲突。在 EAR 项目中，每个模块都有自己的命名空间。

于 2011-03-07T02:52:23.637 回答
2

我在这个主题上做了一些实验，对结果感到非常惊讶。我的结论是永远不会在 WAR 中使用 EJB。让我们把工作留给 EJB 容器，所以如果有人想获得最佳且无错误的开发，请改用 EAR。

当我使用 NetBeans 7.1.3、Glassfish 3.1.2.2 和 JRebel 在 WAR 中使用 EJB 以加快开发速度时，我意识到 JRebel 只有在将 EJB 模块中的更改部署在 EAR 包中时才能完美运行。如果我制作了简单的 WAR 包，那么类加载器在开发阶段的表现绝对很奇怪，并导致了很多随机错误。

无论如何，正常部署中的战争包就像其他人提到的那样完美。

同样在 WAR 包中，NamedQuery 字符串的更改在保存和编译后没有出现。如果我将其打包到 EAR 中，则开发是顺利且快速的。当然，这也可能是 JRebel 中的一个错误。

于 2014-01-09T22:30:48.580 回答