开始一个新项目，想了解在 WAR 与 EAR 中打包 EJB 的优缺点。
当 EJB 处于 WAR 状态时，JNDI 是否仍然有效？效率？等等？
谢谢。
最佳答案
将 EJB bean 放在单独的 JAR 中的一个重要动机是为了实现业务逻辑和 View 逻辑的古老分离。
由于 EJB 应该只专注于业务逻辑，因此将它们放入单独的模块中是有意义的。
这正是传统 Java Enterprise Archive 所提供的便利。 EJB bean 进入代表 EJB 模块 的 JAR 文件，而与 Web 相关的工件(Facelets、支持 bean、实用程序代码)进入代表 的 Web Archive (WAR) 文件。 Web 模块。请注意，WAR 实际上不一定是文件。在所谓的分解格式中，它们只是目录。
这种分离的一个关键方面是这两个模块通过类加载器层次结构隔离。 Web 模块 可以访问EJB 模块 中的资源(通常是bean)，并且EJB 模块 可以引用定义在中的资源(通常是库)。整体 EAR 伞。其他方向是不可能的。具体来说，EJB 模块 无法访问 Web 模块 中定义的任何资源。
这种强制执行是经过深思熟虑的。
业务逻辑应该完全独立于任何 View 技术。强制执行这种隔离可以防止开发人员意外地或在压力下混合这些问题。这种分离的好处是业务逻辑可以被其他 Java SE 客户端、Web 模块客户端、JAX-RS 客户端等轻松使用。如果业务逻辑意外地具有 JSF 或 Servlet 依赖项，那么将很难使用它来自 Java SE 客户端。
将此与不允许使用 scriptlet 的 Facelets 进行比较。这使 Facelets 保持干净，并让它们专注于组件布局和标记。另一个类比是接口(interface)编码，它将契约与实现分开。
因此拥有单独的 EJB 模块实际上是一种最佳实践。然而...
对于较小的项目，可能没有必要进行这种分离，对于初学者来说，可能很难理解什么需要放在哪里的结构。因此，取消强制分离可以让没有经验的开发人员更轻松地开始使用 Java EE。它向他们简要介绍了 Java EE，之后一旦他们了解分层的想法，他们就可以选择引入 EJB 模块。
关于jakarta-ee - 使用 JavaEE 6 WAR 与 EAR 封装 EJB，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4441237/