在 JavaEE 6 WAR 与 EAR 中打包 EJB [英] Packaging EJB in JavaEE 6 WAR vs EAR

问题描述

开始一个新项目，想知道在 WAR 和 EAR 中打包 EJB 的利弊.

Starting a new project and would like to know the pros and cons of packaging EJB in a WAR vs EAR.

当 EJB 处于 WAR 中时，JNDI 仍然有效吗?效率?等等?

Will JNDI still works when EJBs are in the WAR? efficiency? etc.?

谢谢.

推荐答案

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

An important motivation for having EJB beans in a separate JAR is for the age old separation of business logic and view logic.

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

Since EJBs are supposed to concentrate solely on business logic, it makes sense to put them into a separate module.

这正是传统 Java Enterprise Archive 所提供的便利.EJB bean 进入代表 EJB 模块 的 JAR 文件，而 Web 相关工件(Facelets、支持 bean、实用程序代码)进入代表 的 Web Archive (WAR) 文件网络模块.请注意，WAR 实际上不必是文件.在所谓的分解格式中，它们只是目录.

This is exactly what the traditional Java Enterprise Archive facilitates. The EJB beans go into a JAR file which represents the EJB module, while the web related artifacts (Facelets, backing beans, utility code) go into a Web Archive (WAR) file which represents the Web module. Note that a WAR doesn't actually have to be a file. In the so-called exploded format they are merely directories.

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

A key aspect of this separation is that those two modules are isolated via a class loader hierarchy. The Web module has access to resources (typically beans) from the EJB module, and the EJB module can reference resources (typically libraries) defined in the overall EAR umbrella. The other direction is not possible. Specifically, the EJB module cannot access any resources defined in the Web module.

这种强制措施是故意的.

This enforcement is deliberate.

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

Business logic should be completely independent of any view technology. Enforcing this isolation prevents developers from accidentally or when under pressure mixing those concerns anyway. The benefits of this separation is that business logic can trivially be used by among others Java SE clients, Web module clients, JAX-RS clients, etc. If the business logic accidentally had JSF or Servlet dependencies, it would be very hard to use it from Java SE clients.

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

Compare this with Facelets not allowing scriptlets to be used. This keeps the Facelets clean and let them focus on component layout and markup exclusively. Another analogy is with coding to interfaces, which separates the contract from the implementation.

因此，拥有一个单独的 EJB 模块实际上是一种最佳实践.不过……

So having a separate EJB module is actually a best practice. However...

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

For smaller projects it might be unnecessary to have this separation and for beginning programmers it might be difficult to wrap their heads around the structure of what needs to go where. Removing the mandatory separation thus makes it easier for inexperienced developers to start with Java EE. It gives them a gentle introduction into Java EE and later once they get the idea of layering, they can then opt to introduce an EJB module anyway.

这篇关于在 JavaEE 6 WAR 与 EAR 中打包 EJB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！