本文是关于java ee最佳实践的更新版本。这个修正版中考虑了一些不断变化的技术趋势，更重要的是推荐了一些作者认为应当广泛遵循、但尚未广泛遵循的实践……

　　引言

　　在过去的几乎整整十年中，人们编写了很多有关 java™ platform, enterprise edition (java ee) 最佳实践的内容。现在有十多本书籍和数以百计(可能更多)的文章，提供了关于应该如何编写 java ee 应用程序的见解。事实上，这方面的参考资料如此之多，并且这些参考资料之间往往还存在着一些矛盾的建议，以至于在这些混杂的内容中进行学习本身也成为了采用 java ee 的障碍。因此，为了给刚进入这个领域的客户提供一些简单的指导，我们汇编了这个最重要的最佳实践列表，其中包括我们认为最重要和最有效的 java ee 最佳实践。遗憾的是，我们无法仅在 10 大最佳实践中描述所有需要介绍的内容。因此，为了避免遗漏关键的最佳实践和尊重 java ee 的发展，我们的列表中包含了“19 大”关键的 java ee 最佳实践。

　　1. 始终使用 mvc 框架。

　　将业务逻辑(java bean 和 ejb 组件)从控制器逻辑(servlet/struts 操作)和表示逻辑(jsp、xml/xslt)中清晰地分离出来。良好的分层可以带来许多好处。

　　这项实践非常重要，以致没有其他最佳实践可以与其相提并论。对于良好的 java ee 应用程序设计而言，模型-视图-控制器 (mvc) 是至关重要的。它将程序的任务简单地分为下面几个部分：

• 　　负责业务逻辑的部分(模型，通常使用 enterprise javabeans™ 或传统 java 对象来实现)。
• 　　负责用户接口表示的部分(视图)。
• 　　负责应用程序导航的部分(控制器，通常使用 java servlet 或类 struts 控制器这样相关的类来实现)。

　　对于 java ee，有许多关于这个主题的优秀评论，我们特别推荐感兴趣的读者可以参考 [fowler] 或者 [brown]的评论，以便全面和深入地了解相关内容。

　　如果不遵循基本的 mvc 体系结构，在开发过程中就会出现许多的问题。最常见的问题是，将过多的任务放到该体系结构的视图部分中。可能存在使用 jsp 标记来执行数据库访问，或者在 jsp 中进行应用程序的流程控制，这在小规模的应用程序中是比较常见的，但是，随着后期的开发，这样做将会带来问题，因为 jsp 逐步变得越来越难以维护和调试。

　　类似地，我们也经常看到将视图层构建到业务逻辑的情况。例如，一个常见的问题就是将在构建视图时使用的 xml 解析技术直接应用到业务层。业务层应该对业务对象进行操作，而不是对与视图相关的特定数据表示进行操作。

　　然而，仅仅使用适当的组件无法实现应用程序的正确分层。我们常常见到一些应用程序包含 servlet、jsp 和 ejb 组件所有这三项，然而，其主要的业务逻辑却是在 servlet 层实现的，或者应用程序导航是在 jsp 中处理的。您必须对代码进行严格的检查和重构，以确保仅在模型层中处理业务逻辑，在控制器层中进行应用程序导航，而视图应该只关心如何将模型对象呈现为合适的 html 和 javascript™。

　　本文中这项建议的涵义应该比原始版本中的更加清楚。用户接口技术不断地发生着变化，将业务逻辑关联于用户接口，会使得对接口的更改影响到现有的系统。几年之前，web 应用程序用户接口开发人员可能从 servlet 和 jsp、struts 和 xml/xsl 转换中进行选择。在那以后，tiles 和 faces 非常流行，而现在，ajax 大行其道。如果每当首选的用户接口技术发生了更改就要重新开发应用程序的核心业务逻辑，那么就糟透了。

　　2. 不要做重复的工作。

　　使用常见的、经过证实的框架，如 apache struts、javaserver faces 和 eclipse rcp。使用经过证实的模式。

　　回到我们开始帮助客户使用刚出现的 java ee 标准的时候，我们发现(和许多其他人一样)，通过直接使用基础的 servlet 和 jsp 规范构建 ui 应用程序来开发用户接口开发框架，可以极大地提高开发人员工作效率。因此，许多公司开发了他们自己的 ui 框架，这些框架可以简化接口开发的任务。

　　随着开放源码的框架(如 apache struts)的出现 [brown]，我们相信，可以自动地和快速地转换到这些新的框架。我们认为，使用开放源码社区支持的框架非常适合于开发人员，并且这些框架很快得到了广泛认可，不仅可用于新的开发，还可以修改现有的应用程序。

　　但令人感到奇怪的是，事实并非如此。我们仍可以看到许多公司在维护或甚至开发新的用户接口框架，而这些框架的功能与 struts 或者 jsf 是完全相同的。之所以会出现这种情况，有许多原因：机构惰性，“非我发明”症，不了解更改现有代码的好处、或者甚至傲慢地认为能够比开放源码开发人员的特定框架做得更好。

　　然而，这些原因都已经过时了，不能够成为不采用标准框架的借口。struts 和 jsf 不仅在 java 社区中得到了广泛认可，而且还受到 websphere 运行时和 rational® 工具套件的全面支持。同样地，在富客户端领域中，eclipse rcp(富客户端平台，rich client platform)获得了广泛的认可，可用于构建独立的富客户端。尽管不是 java ee 标准中的一部分，但这些框架现在已成为 java ee 社区的一部分，并且理应如此。

　　对于那些因为傲慢而不愿使用现成的 ui 框架的人，应该阅读 [alur] 和 [fowler] 中介绍的内容。这两本书详细地描述了企业 java 应用程序中最常用的可重用模式。从类似于会话 facade 这样简单的模式(将在后面的建议中讨论)到类似于 fowler 持久性模式(许多开放源码的持久性框架对其进行了实现)这样比较复杂的模式，其中的内容体现了 java 前辈们所积累的智慧。那些不能吸取教训的人必定会重蹈覆辙(如果他们非常幸运，能够在第一次失败之后获得重来一次的机会)，他们不得不向哲学家 santayana 说抱歉。

　　3. 在应用程序的每一层都使用自动单元测试和测试管理。

　　不要只是测试您的图形用户界面(gui)。分层的测试使得调试和维护工作变得极其简单。

　　在过去的几年中，在方法学领域有了相当大的革新，例如新出现的被称为 agile(如参考资料部分中的 scrum [schwaber] 和极限编程 [beck1])的轻量级方法现在已经得到了很普遍的应用。几乎所有的这些方法中的一个共同特征是它们都提倡使用自动的测试工具，这些工具可以帮助开发人员用更少的时间进行回归测试，并可以帮助他们避免由于不充分的回归测试造成的错误，因此可以用来提高程序员的工作效率。实际上，还有一种被称为 test-first development [beck2] 的方法，这种方法甚至提倡在开发实际的代码之前就先编写单元测试。然而，在您测试代码之前，您需要将代码分割成一些可测试的片断。一个“大泥球”是难以测试的，因为它不是只实现一个简单的易于识别的功能。如果您的每个代码片断实现多个方面的功能，将难以测试其中的每个部分以保证其正确性。

　　mvc 体系结构(以及 java ee 中的 mvc 实现)的一个优点就是元素的组件化能够(实际上，相当的简单)对您的应用程序进行单元测试。因此，您可以方便地对实体 bean、会话 bean 以及 jsp 独立编写测试用例，而不必考虑其他代码。现在有许多用于 java ee 测试的框架和工具，这些框架及工具使得这一过程更加简单。例如，junit(是一种由 junit.org 开发的开放源代码工具)和 cactus(由 apache 协会开发的开放源代码工具)对于测试 java ee 组件都非常有用。[hightower] 详细探讨了如何在 java ee 中使用这些工具。

　　尽管所有这些详述了怎样彻底地测试您的应用程序，但是我们仍然看到一些人认为只要他们测试了 gui(可能是基于 web 的 gui，或者是独立的 java 应用程序)，则他们就全面地测试了整个应用程序。仅进行 gui 测试是不够的。gui 测试很难达到全面的测试，有以下几种原因。

• 　　使用 gui 测试很难彻底地测试到系统的每一条路径，gui 仅仅是影响系统的一种方式。可能存在后台运算、脚本和各种各样的其他访问点，这也需要进行测试，然而，它们通常并不具有 gui。
• 　　gui 级的测试是一种非常粗粒度的测试。这种测试只是在宏观水平上测试系统的行为，这意味着一旦发现存在问题，则与此问题相关的整个子系统都要进行检查，这使得找出错误将是非常困难的事情。
• 　　gui 测试通常只有在整个开发周期的后期才能很好地得到测试，这是因为只有这那个时候 gui 才得到完整的定义。这意味着只有在后期才可能发现潜在的错误。
• 　　一般的开发人员可能没有自动的 gui 测试工具。因此，当一个开发人员对代码进行更改时，没有一种简单的方法来重新测试受到影响的子系统。这实际上不利于进行良好的测试。如果开发人员具有自动的代码级单元测试工具，开发人员就能够很容易地运行这些工具以确保所做的更改不会破坏已经存在的功能。
• 　　如果添加了自动构建功能，则在自动构建过程中添加一个自动的单元测试工具是非常容易的事情。当完成这些设置以后，整个系统就可以有规律地进行重建，并且回归测试几乎不需要人的参与。

　　另外，我们必须强调，使用 ejb 和 web 服务进行分布式的、基于组件的开发使得测试单个组件变得非常必要。如果没有“gui”需要测试，您就必须进行低级(lower-level)测试。最好以这种方式开始测试，省得当您将分布式的组件或 web 服务作为您的应用程序的一部分时，您不得不花费心思重新进行测试。

　　总之，通过使用自动的单元测试，能够很快地发现系统的缺陷，并且也易于发现这些缺陷，使得测试工作变得更加系统化，因此整体的质量也得以提高。

……