随着开放源码的框架（ 如 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] 的方法，这种方法甚至提倡在 开发实际的代码之前就先编写单元测试。然而，在您测试代码之前，您需要将代 码分割成一些可测试的片断。一个“大泥球”是难以测试的，因为它 不是只实现一个简单的易于识别的功能。如果您的每个代码片断实现多个方面的 功能，将难以测试其中的每个部分以保证其正确性。

最重要的Java EE最佳实践(3)

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

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!