《建造灵活与可维护的J2EE应用程序的设计模式（一）》中学教育科普读物.pdfVIP

建造灵活与可维护的J2EE 应用程序的设计模式 Vijay Ramachandran 2002 年 1 月 TM TM 鉴于Java 2 企业版(J2EE ) 已经成为服务器端应用程序平台的首选，共享开 发者的经验与设计就成了一件至关紧要的事。本文介绍了一些可重复使用的设计 模式，以便读者在建造灵活与容易维护的J2EE 应用程序时使用。 本文不对范例的正式摸板与UML 图作介绍。您可以在J2EE 蓝图程序找到这些 细节与代码样例。本文所要解决的是那些能够影响J2EE 应用程序灵活性和可维 护性的问题，并且给出推荐的解决方案。 什么是设计模式？ 当您设计建造不同的应用程序时，您时而不时地会碰到相同或者非常类似的问题 域。每次碰到这些问题时您都必须去重新寻找解决方案。为了节省时间与精力， 如果有一个知识库，能够捕获这样的具有共性的问题域与被证明是正确的解决方 案，将是非常理想的。 用最简单的话来说，这样的通用解决方案就是一个设计模式。这样的知识库，或 者说参考处，包含了这些模式，就是设计模式目录。 设计模式描述的是已被经验证明过可行的解决方案，以便一个重复出现的设计问 题使用。这些解决方案具有普遍性。设计模式使用一种被良好定义过的模式摸板 进行描述，比如最流行的、由“四个伙计”(Gang of Four)定义的摸板。 模式摸板通常包含一个用来描述模式所代表的意义的名字，紧跟着的是模式的适 用范围、动机、在实现过程中的问题等等。除了描述问题与阐明解决方案，模式 还解释在使用本模式的实现过程中可能存在的问题和后果。 使用这样的模式让应用程序的设计变得透明。这些模式已经被不同的开发者在不 同的领域内成功地使用过，所以，一个模式的优点和缺点（也包括实现过程中的 问题）都已经事先知道。所有的设计模式都是可重复使用的，并且在特定的场合 中适用。这就给了您灵活性。同J2EE 应用程序有关的设计模式的使用在J2EE 平台技术方面提供了更多优势来展示了解决方案。 建造灵活与可维护的J2EE 应用程序的设计模式 多层的J2EE 应用程序由位于中间层的一些可能是分布式的不同视图和组件组 成。在本文的以下章节中，给出了一些能帮助您让典型的J2EE 应用程序具备可 扩展性、灵活性和可维护性的设计模式。本文不使用那些抽象的文字，而使用了 一个假想的实际例子，试图让您尽可能地理解这些模式。一旦您了解了这个应用 程序例子，您就能很容易地将这个例子中使用的模式应用到其他应用程序中。 以一个Web 上的金融服务企业级应用程序作为例子。浏览者可以在这个站点上 浏览服务项目列表、建造帐户、订购该金融服务机构提供的各种产品等等。我们 假定这个应用程序允许已有的客户改变各自的帐户细节与个人资料，并使用这些 服务，等等。典型地，这样的应用程序有多个视图或者屏幕，用户可以通过鼠标 点击，在这些视图间切换，查找服务项目列表，存取个人资料，使用各种服务项 目，或者取得其他信息。事务逻辑代表着用户的帐户、资料、服务目录、服务定 单等等，这种形式就如同在企业版JavaBeans(EJB)中的分开的实体。把这个 例子放在心里，然后再看看那些重复的问题，您就能明白如何使用特定的模式来 建造灵活的、可维护的应用程序。 模型-视图-控制器 问题域 如果您所建造的这个企业级应用程序只是给单一类型的客户使用的，那问题就简 单了。我们可以简单地将数据存取/数据修改逻辑与不同的客户视图逻辑混合在 一起。但是随着一个完全互连的无线世界的出现，客户端的设备从PDA、蜂窝 电话到一个功能强大的桌面系统上的浏览器都有，这还不包括其他的传统设备。 在这种情况下，将数据存取与视图混合在一起来作为解决方案，将会有很多问题， 这是因为： • 您必须开发这个应用程序的不同版本，以便适应与支持各种不同的客户需要 • 由于视图的代码与数据存取/修改的代码纠缠在一起，重复的数据存取/修改代码散 步在各处，这就使得应用程序几乎是不可维护的。 • 开发生命周期被不必要地扩展了 建议的解决方案 为了找到这个问题的解决方案，请注意以下几点： • 不论客户类型如何，被存取与显示的数据必须来自同一个企业级的数据源。 • 所有的客户必须能够对数据源进行修改