最佳实践
1、始终使用 MVC 框架。
2、在每一层都应用自动单元测试和测试治理。
3、按照规范来进行开发，而不是按照应用服务器来进行开发。
4、从一开始就计划使用 J2EE 安全性。
5、创建您所知道的。
6、当使用 EJB 组件时，始终使用会话 Facades。
7、使用无状态会话 bean，而不是有状态会话 bean.
8、使用容器治理的事务。
9、将 JSP 作为表示层的首选。
10、当使用 HttpSession 时，尽量只将当前事务所需要的状态保存其中，其他内容不要保存在 HttpSession 中。
11、在 WebSphere 中，启动动态缓存，并使用 WebSphere servlet 缓存机制。
12、为了提高程序员的工作效率，将 CMP 实体 bean 作为 O/R 映射的首选解决方案。
1. 始终使用 MVC 框架。
MVC 框架可以将业务逻辑（Java beans 和 EJB 组件)、控制器逻辑（Servlets/Struts 动作）、表示层（JSP、XML/XSLT）清楚地分离开来。良好的分层可以带来许多好处。
MVC 框架对于成功使用 J2EE 是如此重要，以致没有其他最佳实践可以与其相提并论。模型-视图-控制器（MVC）是设计 J2EE 应用程序的基础。MVC 将您的程序代码简单地划分下面几个部分：
·负责业务逻辑的代码（即模型——通常使用 EJB 或者普通的 Java 对象来实现）。
·负责用户界面显示的代码（即视图——通常通过 JSP 及标记库来实现，有时也使用 XML 和 XSLT 来实现）。
·负责应用程序流程的代码（即控制器——通常使用 Java Servlet 或像 Struts 控制器这样的类来实现）。
假如您不遵循基本的 MVC 框架，在开发过程中就会出现许多的问题。最常见的问题就是在视图部分添加了太多的成分，例如，可能存在使用 JSP 标记来执行数据库访问，或者在 JSP 中进行应用程序的流程控制，这在小规模的应用程序中是比较常见的，但是，随着后期的开发，这样做将会带来问题，因为 JSP 逐步变得越来越难以维护和调试。
类似地，我们也经常看到将视图层构建到业务逻辑的情况。例如，一个常见的问题就是将在构建视图时使用的 XML 解析技术直接应用到业务层。业务层应该对业务对象——而不是绑定到视图的特定数据表示进行操作。
然而，只是具有合适的组件并不一定意味着可以使您的应用程序得到合适的分层。我们经常见到一些应用程序包含 servlet、JSP 和 EJB 组件所有这三项，然而，其主要的业务逻辑却是在 servlet 层实现的，或者应用程序导航是在 JSP 中处理的。您必须进行严格的代码检查并重构您的代码，以确保应用程序的业务逻辑只在模型层（Model layer）进行处理，应用程序导航只通过控制器层（Controller layer）进行处理，而您的视图（Views）只是将传递过来的模型对象以 HTML 及 JavaScript 的形式表示出来。
2. 在应用程序的每一层都使用自动单元测试和测试治理。
不要只是测试您的图形用户界面（GUI)。分层的测试使测试及维护工作变得极其简单。
在过去的几年中，在方法学领域有了相当大的革新，例如新出现的被称为 Agile（例如 SCRUM [Schwaber] 和极限编程 [Beck1]）的轻量级方法现在已经得到了很普遍的应用。几乎所有的这些方法中的一个共同的特征是它们都提倡使用自动的测试工具，这些工具可以帮助开发人员用更少的时间进行回归测试 (regression testing)，并可以帮助他们避免由于不充分的回归测试造成的错误，因此可以用来提高程序员的工作效率。实际上，还有一种被称为 Test-First Development [Beck2] 的方法，这种方法甚至提倡在开发实际的代码之前就先编写单元测试。然而，在您测试代码之前，您需要将代码分割成一些可测试的片断。一个"大泥球"是难以测试的，因为它不是只实现一个简单的易于识别的功能。假如您的每个代码片断实现多个方面的功能，这样的代码将难以保证其完全的正确性。
MVC 框架（以及 J2EE 中的 MVC 实现）的一个优点就是元素的组件化能够（实际上，相当的简单）对您的应用程序进行单元测试。因此，您可以方便地对实体 bean、会话 bean 以及 JSP 独立编写测试用例，而不必考虑其他的代码。现在有许多用于 J2EE 测试的框架和工具，这些框架及工具使得这一过程更加简单。例如，JUnit（是一种由 junit.org 开发的开放源代码工具）和 Cactus（由 Apache 开发的开放源代码工具）对于测试 J2EE 组件都非常有用。[Hightower] 具体探讨了如何在 J2EE 中使用这些工具。
尽管所有这些详述了怎样彻底地测试您的应用程序，但是我们仍然看到一些人认为只要他们测试了 GUI（可能是基于 Web 的 GUI，或者是独立的 Java 应用程序），则他们就全面地测试了整个应用程序。GUI 测试很难达到全面的测试，有以下几种原因。首先，使用 GUI 测试很难彻底地测试到系统的每一条路径，GUI 仅仅是影响系统的一种方式，可能存在后台运算、脚本和各种各样的其他访问点，这也需要进行测试。然而，它们通常并不具有 GUI。第二，GUI 级的测试是一种非常粗粒度的测试。这种测试只是在宏观水平上测试系统的行为。这意味着一旦发现存在问题，则与此问题相关的整个子系统都要进行检查，这使得找出 bug（缺陷）将是非常困难的事情。第三，GUI 测试通常只有在整个开发周期的后期才能很好地得到测试，这是因为只有这那个时候 GUI 才得到完整的定义。这意味着只有在后期才可能发现潜在的 bug。第四，一般的开发人员可能没有自动的 GUI 测试工具。因此，当一个开发人员对代码进行更改时，没有一种简单的方法来重新测试受到影响的子系统。这实际上不利于进行良好的测试。假如开发人员具有自动的代码级单元测试工具，开发人员就能够很轻易地运行这些工具以确保所做的更改不会破坏已经存在的功能。最后，假如添加了自动构建功能，则在自动构建过程中添加一个自动的单元测试工具是非常轻易的事情。当完成这些设置以后，整个系统就可以有规律地进行重建，并且回归测试几乎不需要人的参与。
另外，我们必须强调，使用 EJB 和 Web 服务进行分布式的、基于组件的开发使得测试单个的组件变得非常必要。假如没有"GUI"需要测试，您就必须进行低级（lower-level）测试。最好以这种方式开始测试，省得当您将分布式的组件或 Web 服务作为您的应用程序的一部分时，您不得不花费心思重新进行测试。
