在JavaEE 6 WAR vs 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）文件代表 Web模块。请注意，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客户端等使用。如果业务逻辑意外地具有JSF或Servlet依赖性，那么使用它将非常困难。来自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 vs EAR中打包EJB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！