文档介绍：12 个最重要的 J2EE 最佳实践详解完整版 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 (是一种由 开发的开放源代码工具)和 Cactus (由 Apache 开发的开放源代码工具) 对于测试 J2EE 组件都非常有用。[Hightower] 详细探讨了如何在 J2EE 中使用这些工具。尽管所有这些详述了怎样彻底地测试您的应用程序, 但是我们仍然看到一些人认为只要他们测试了 GUI (可能是基于 Web 的 GUI ,或者是独立的 Java 应用程序) ,则他们就全面地测试了整个应用程序。 GUI 测试很难达到全面的测试, 有以下几种原因。首先, 使用 GUI 测试很难彻底地测试到系统的每一条路径, GUI 仅仅是影响系统的一种方式,可能存在后台运算、脚本和各种各样的其他访问点,这也需要进行测试。然而, 它们通常并不具有 GUI 。第二, GUI 级的测试是一种非常粗粒度的测试。这种测试只是在宏观水平上测试系统的行为。这意味着一旦发现存在问题, 则与此问题相关的整个子系统都要进行检查,这使得找出 bug (缺