开始一个新项目，想了解在 WAR 与 EAR 中打包 EJB 的优缺点。
当 EJB 处于 WAR 状态时，JNDI 是否仍然有效？效率？ ETC。？
Thanks.
将 EJB bean 放在单独的 JAR 中的一个重要动机是为了古老的分离商业逻辑 and 查看逻辑.
由于 EJB 应该只关注业务逻辑，因此将它们放入单独的模块中是有意义的。
这正是传统 Java Enterprise Archive 所提供的便利。 EJB bean 进入一个 JAR 文件，该文件代表EJB module，而与 Web 相关的工件（Facelets、支持 Bean、实用程序代码）则进入 Web 存档 (WAR) 文件，该文件代表Web module。请注意，WAR 实际上不一定是文件。在所谓的分解格式中，它们只是目录。
这种分离的一个关键方面是这两个模块是isolated通过类加载器层次结构。这Web module可以访问来自的资源（通常是bean）EJB module，以及EJB module可以引用整个 EAR 保护伞中定义的资源（通常是库）。其他方向是不可能的。具体来说，EJB module无法访问中定义的任何资源Web module.
这种强制执行是经过深思熟虑的。
业务逻辑应该完全独立于任何视图技术。强制执行这种隔离可以防止开发人员意外地或在压力下混合这些问题。这种分离的好处是业务逻辑可以被其他 Java SE 客户端、Web 模块客户端、JAX-RS 客户端等轻松使用。如果业务逻辑意外地具有 JSF 或 Servlet 依赖项，那么将很难使用它来自 Java SE 客户端。
将此与不允许使用 scriptlet 的 Facelets 进行比较。这使 Facelets 保持干净，并让它们专注于组件布局和标记。另一个类比是接口编码，它将契约与实现分开。
因此，拥有一个单独的 EJB 模块实际上是最佳实践。然而...
对于较小的项目，可能没有必要进行这种分离，而对于初学者来说，可能很难理解什么需要放在哪里的结构。因此，取消强制分离可以让没有经验的开发人员更轻松地开始使用 Java EE。它向他们简要介绍了 Java EE，随后他们get分层的想法，然后他们可以选择引入EJB module anyway.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
