这些框架可以简化接口开发的任务。
　　随着开放源码的框架(  

如 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 的
轻量级方法现在已经得到了很普遍的应用。几乎所有的这些方法中的一个共同特征是它们
都提倡使用自动的测试工具，这些工具可以帮助开发人员用更少的时间进行回归测试，
并可以帮助他们避免由于不充分的回归测试造成的错误，因此可以用来提高程序员的工

 

作效率。实际上，还有一种被称为 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 测试很难达到全面的测试，