实用2E设计模式 编程指南 C性 乐思 PUB. COM
目录 第1章J2EE设计模式 模式的演变 软件工程中的模式 何谓设计模式 标识模式 表示设计模式 设计模式如何帮助解决问题 选择适当的设计模式 使用设计模式 因素改变 反模式 J2EE与设计模式 2EE模式的问题域 小结 第2章Web层设计模式 表示模式 案例:宾馆订房管理系统… 标识模式 小结 第3章持久性框架设计模式 开始模型 何谓持久性框架 TitleDAO会话Bean… Value Object模式 Service Locator模式 使用持久性框架 持久性框架策略 小结 第4章改进性能与伸缩性的设计模式 性能问题的原因
实用J2EE设计模式编程指南 伸缩性问题的原因 城市休假订票应用程序, 标识提高性能的模式 136 标识提高伸缩性的模式 完整 City Break体系结构 第5章管理安全性的设计模式 何谓安全模式 Wrox Web Banking用例… 实现案例 小结 第6章企业集成设计模式 何谓企业应用程序集成(EAI) J2EE集成模式 简单集成情形 217 实现集成模式 在B2B集成中使用集成模式 小结 第7章复用性、可维护性与扩展性设计模式 为何编写可复用软件 为何编写可维护软件 为何编写可扩展软件 257 基于组件的案例 Decorator设计模式
第1章J2EE设计模式 第1章J2EE设计模式 即使利用最先进的软件平台Java2 Platform Enterprise Edition(J2EE),开发企业应 用程序仍然是个难题。J2EE通过AP提供技术与服务的高层抽象,使企业开发得到简化。但 是,仅仅知道J2EEAP是不够的。要设计良好的体系结构,得到高质量的应用程序,就要 知道何时如何正确使用J2 EE API本书介绍如何正确使用J2 EE API、技术与服务。 由于新技术方面的经验缺乏,我们通常要自已猜测如何正确使用。通常很难第一步就 走对,而是要不断试验,直到找出最佳方法。最佳方法显然是从实践中得到的,不是发明出 来的,而是发现和改善而成的 工程学科中的一大原则是总结经验和利用实践证明有效的方案,企业应用程序也是这 样。经验有助于更快更顺利地建立良好方案,从而节省成本,提高质量。惟一的问题是需要 获得经验,但这个经验可以是别人的间接经验,而不一定非要是自己的直接经验。本书帮助 读者节省自己的时间,介绍如何根据许多开发人员的间接经验进行合理设计。 但是,别人的经验如何描述昵?多年来,模式已经成为收集、规范和分析某些情境中 常见问题的有效方法。本书主要介绍J2EE设计模式,不仅介绍2EE企业开发中的常见向题 及其解决方案,而且介绍其如何运用到实际项目中 本章概述模式,并特别介绍设计模式与J2EE,同时介绍一些准则,如怎样有效利用设 计模式。本章介绍的内容包括 模式的演变 ·何谓设计模式 ·标识模式 设计模式如何解决设计问题 选择设计模式 ·使用设计模式 ·反模式 ·J2EE与设计模式 J2EE特定模式与J2EE情境中的模式 J2EE模式的问题域 模式的演变 设计模式是从建筑与民用工程开始的。20世纪70年代,建筑学是需要大量经验的学科 hris-topher Alexander等的三本著作震惊了整个行业,使不需要太多专门知识与经验的人也 可以使用建筑学。他们标识有效结构之间的相似性,确定共同原则,作为常见设计问题的方 案,并将其命名为建筑学中的方案“模式
实用J2EE设计模式编程指南 但是,发布253个模式之后, Christopher Alexander仍然没能使建筑学成为机械化过程 那么,这些建筑模式有什么重要性呢?模式的目标并不是使建筑学成为机械化过程,而是为 了普及常见建筑间題的解决方案,使经验较少的建筑师能更高效地进行设计,这是建筑模式 的主要目标。 建筑模式对其他工程学科产生了巨大的影响。显然,每个成熟的工程学科都应建立常 见问题的解决方案,软件工程也不例外,叮以用模式成功地描述常见软件问题的解决方案 模式不仅提供良好方案,而且还叮以帮助人们进行沟通,帮助他们分析工作和寻找原因。 软件工程中的模式 软件工程中的模式是什么呢?没有一个公认的定义 简单地说,模式就是情境中一个问题经过证实的一个方案 但是,这个简单定义可能造成对模式的误解。 Christopher Alexander写道: “每个模式描述一个在我们的环境中不断重复出现的问題,然后描述这个问题的方案 核心,使你可以多次使用同一方蒙,而不必进行重复工作。” 近年来关于软件工程中的模式的最有影响的出版物是《 Design Patterns: Elements of Reusable Object-Oriented Software》,作者 Erich Gamma、 Richard helm、 Ralph Johnson John Vlissides称为四人帮, Addison-Wesley出版公司出版(ISBN:0201-63361-2)。其定 模式如下 “模式是三段值,表示特写情境、问题与方蒙之间的关系。” 根据这个定义,模式是多种情形中可以使用的问题解。 Richard Gabriel提供了一个有趣的定义 毎个模式是三段值,表示情境,这个情境中重复出現的问题及解决这些问題的一定 软件配置之间的关系。” 模式是从经验中总结出来的,基于经过证实的方案。模式只有在实际系统中多次得到 验证之后才能成为模式。因此,模式一方面促进复用,一方面又防止重复劳动,最终使我们 能更快更高效地工作。 模式还增加表达能力,改进建筑师与设计人员之间的通信,使我们可以按前所未有的 方式考虑常见结构性方案。模式鼓励通过结合解决大问题, 由此可见,模式没有什么新东西。有经验的设计人员可以阅读模式和发现过去的处理 方法。众所周知,专家并不从低级结构考虑问题,而是建立高级抽象。但模式则鼓励人们标 识记录这些高级抽象。标识模式的动机包括: 寻找模式靠经验而不是靠想像。想像会引入风险,因为新的方法!技术要经过验证 1j测试之后才能证明有用。实际中,成功通常比想像更重要。因此,新的模式要终 过试验才能评估其 好的模式是从实践中总结出来的
第1章J2EE设计模式 模式能改进开发人员之间的通信,使他们可以更快地学习,从而开发更好的软件 为了达到高效通信,我们要用某种方式表示模式,最好使用标准格式。稍后将介绍 表示模式的格式 模式叮以按照质和量验证知识,从而评估其价值。这样町以表示与理解模式及所建 体系结构的利弊 模式几乎无所不在。多年来,出现了多种不同的软件模式,包括 ·设计模式,包括软件设计,可能是最重要的模式。通常是面向对象的,包括体系结 构(系统设计)、设计(组件交互)和编程(特定语言技术)。本书主要介绍设计 模式。 分析模式,描述可复用分析模型,在域分析中非常有用,涉及各种域,包括交易、度 量、会计和组织关系。要了解分析模式的更多信息,见《 Analysis Pattems: Reusable Object Model》-书, Addison-Wesley出版(ISBN0-201-89542-0) 过程模式,描述软件过程设计。具体地说,它们描述开发软件成功而经过证实的方 法与活动。详见剑桥大学出版社的《 Process patterns: Building Large- Scale Systems Using Object Technology)(ISBN 0-521-64568-9)<More Process Patterns Delivering Large-Scale Systems Using Object Technology)(ISBn 0-521-65262- 6) 组织模式,描述组织与项目的结构和实践。详见htp:/i44pc48.nfo. uni-karlsruhe. de/ cgi-bin/OrgPatternso ·实现模式,描述实现概念。详见《 Essential Java Style: Patterns for Implementation 书, Prentice Hal版(ISBN0-13-085086-1)。 ·其他域特定模式 模式还可以根据包括的问题分为: 创建性模式 结构性模式 行为性模式 可以看出,模式有几个抽象层,可以按不同方式分类。本书主要介绍J2EE设计模式 首先介绍设计模式。 何谓设计模式 设计模式是情境中标准设计问题的重复性解决方案。设计问题必须进一步调查之后才 能解决。问题通常发生在定的环境或情形中,称为情境。解决方案是这些问题的答案,帮 助我们在一定情境中解决这些问题。 例如,假设有一个小房间,问题是把门放在哪里更方便。经过不同测试之后,我们可 能发现应把门放在房间的东南角。这样就找到了特定问题的解。同样,软件设计中也可以找 到特定问题的解
实用J2EE设计模式编程指南 设计问题的解是否都是设计模式呢?不一定。设计模式只是适用于不同情境的解,即 可以重复采用,在不同情境中解决同一问题。 回到房门的问题,这个解还不能作为模式,因为它只限于这个特定情形。但如果能对 所有小房间找到一般解,则可以称为模式。 Alexander就是这么干的。他发现,房门不能放 在墙上任何地方。此外,房间的成功很大程度上取决于门的位置。因此,他建议除了很大的 房间之外,房门应尽量靠近墙角。他把这个模式称为角门( Comer doors)模式 虽然这是一个简单概念,但定义设计模式并不容易。因此,人们提出了五花八门的定 义。为了深入了解设计模式,下面再进一步解释。 设计模式针对软件设计,系统化地命名、解释和求值重要软件设计。设计模式使成功 地经过证明的设计与体系结构更容易复用,使新系统开发人员能更方便地釆用设计模式,特 別是经验较少的开发人员。设计模式能帮助我们选择不同设计。本书主要介绍设计模式,因 此此后“模式”一词特指设计模式 假设要开发 Customer实体Bean,并把客户数据提供给客户机。自然方法是用细粒方法定 远程接口(如 get/setNameO、 get/setAddres0),让远程客户机直接访间这个实体Bean。要 确定这个解不可伸缩,因此不适合实际应用,需要实现组件与客户机,进行部署和测试,需 要进行大量工作。记住,实际应用程序中通常要面对多个组件,而不只是 Customer 知道 Value Object!与 iSession Facade之类的设计模式之后,就很容易看出EJB的远程接口 应是粗粒的。 Value Object(数值对象)模式显示了如何使接口变成粗粒,同时以巧妙的方式 传输所有必要的数据,避免多次远程方法调用。 Session Facade模式显示不能直接访间实体 bean,而应开发会话bean,作为门户。如果能对实体bean增加一个本地接口,在同一容器中部 署两个EJB,则可以进一步提高性能 如果你不熟悉 Value Object与 Session Facade模式,则不容易理解上段的内容。别担心, 这些模式都将在本书稍后详细介绍。但可以注意,这两个模式都适用于某种情境。所有模式 都适用于某种情境,是一组矛盾的平衡。描述模式时,我们要明确定义所有这些项目。根据 前面提到的四位专家对设计模式的描述,模式具有四大要素 模式名,标识模式,增加表达性。 ·问题,描述何时应用这个模式,解释问题与情境 ·解,不描述具体设计与实现,而是描述模式模板,叮以在不同情境中使用。 ·结果,是采用一个模式的结果与取舍。结果对评估不同方法和进行决策至关重要。 设计模式描述如何在特定情境中解决一般设计问题。 计模式对常见设计结构的关键方面进行命名、抽象和标识。标识方案参与者,他们 的角色与责任及合作方式。大多数情况下,这些参与者是对象与组件。每个设计模式针对特 定问题。每个模式还描述其结果和取舍。 相关模式交织在一起,构成模式语言。模式语言不是正式语言,而是一组相关模式的 集合。模式和模式语言有助于更好、更快、更有效地学习、通信和解决问题。本书主要介绍 J2EE的模式语言,但介绍J2EE设计模式及其应用之前,先要介绍如何标识模式
第1*J2EE设计模式 标识模式 标识模式要靠经验。每个有经验的建筑师和设计人员能够看到,在大部分项目中会遇 到类似问题,这些问题的解也是相似的。当然,实际解不一定是相同的。但是,所有解具有 相同的基本概念。从抽象角度看,可以说所有这些解与问题表示具有共同抽象解的共同抽象 问题 了解这一点是标识模式的基础。我们应回顾过去的项目,标识处理过的问题。对每个 问题,应标识其特征,还应记录这些问题的解。然后收集类似问题与解,确定其相似性 类似解很可能表示一个模式。前面曾介绍过 Alexander的角门模式, Alexander通过大量 房间中门的布置位置找到这个模式。所有把门放在角上的房间都采用这种模式。前面介绍的 Value Object与 Session Facade模式也是这样,也是通过分析多个应用程序而得到的。 但是,一组解只有经过验证之后才能成为模式。由于 Alexander验证把门放在角上是有 用的,我们也要验证所找到的模式。在软件L程中验证复杂模式可能比验证角门模式之类的 简单建筑模式更复杂。 因此,我们不是直接标识模式,而是标识模式候选者。模式候选者是独立方案,i外 部的连接越少越好。记住,模式是为了复用。我们要验证模式候选者,通常使用三规则,即 每个模式候选者至少要在三个不同系统中证明之后才能成为真正的模式。这个规则不太精确 因此本书作者建议模式候选者应尽量多次验证,使模式更有实用价值 没有充分验证的模式可能带来大量危害。为什么呢?因为大多数建筑师、设计人员和 开发人员并不标识模式,可能没有时间,也可能没有这方面的经验。但他们通常都学习模式 和用其改进解决方案。无法达到目标的模式可能对大量应用程序造成伤害,从而给模式带来 不好的名声。 另一个重要问题是模式应采用哪一级抽象,包括多少实现细节。J2EE模式社区中普遍 接受的概念是模式应釆用高层抽象,但每个模式应包括解的细节。这些解的细节通常比模式 本身采用更低层抽象,称为策略。显然,模式与策略之间没有明显的分界。 由于本书介绍模式,因此会通过这些策略显示不同情境中如何采用模式。 在 Prentice Hall Ptr出版的《 Core j2 EE Patterns》一书(ISBN0-13064884-1)中 作者定义了模式与策略的下列差别 模式应采用更高层抽象,因此应提出最佳实现策略。 开发人员可以通过策略扩展使用模式,寻找实现模式的新方法。 ·模式与策略名称改进通信。 标识模式之后,要表示模式。下节介绍如何表示设计模式 表示设计模式 表示模式和定义模式一样难,仅仅靠统一建模语言(UML)之类的简单图形表示方法是 不够的。为了使模式真正促进复用,就要表示意图、动机、决策、后果,等等。要成功运用
实用]2EE设计模式编程指南 模式,就应提供具体例子 近年来,人们找到了多种模式。标识这些模式的作者将其发表到模式类别中。也诈最 重要的模式类别是前面提到的四位专家在设计模式中提供的23种模式。对J2EE开发人员,模 式类别是个社区过程,见JavaDeveloperConnection站点hp:java.sun.com。EE开发人员 的另一重要模式类别见htp/ww. The ServerSide. com/ 模式可以用正式与非正式方式表示。如今大多数模式类别用非正式方式表示模式。但 问题是他们不用相同格式,而采用稍有不同的格式。模式表示的主要差别源于不同类型模式 解决的设计问题并不相似。例如,前面提到的四位专家的模式解决面向对象设计问题,而核 心J2EE模式解决建立J2EE应用程序时遇到的问题 非正式方式表示模式时通常使用几段,有些是大多数表示中都有的,有些是不同的 大多数非正式方式表示基于前面提到的四位专家的著作中使用的表示。前面提到的四位专家 的著作中使用的表示采用下列模板: Pattern name and classification(模式名与类别) 每个模式应有惟一名称,使模式便于口头表达。 Intent(意图) 简要描述模式的作用、理由与意图、解决的设计向题 Also Known as(别名) 提供模式的别名名单。 Motivation(动机) 描述问题内容及如何用这个模式解决这个问题。 Applicability(适用性) 描述设计模式的适用情形,不好的设计例子及如何识别。 Structure(结构) 提供图形表示,可以使用UML图形。 Participants(参与者) 显示参与这个设计模式的类、对象和组件,及各处的责任。 Collaborations(协作) 描述参与者如何协作 Consequences(后果) 列出模式如何达到目标,使用模式的结果与取舍。 Implementation(实现) 实现模式的提示、技术与策略,以及特定语言问题和注意事项。 Sample code(样本代码) 显示如何实现模式样本代码 Known uses(已知用途) 实际系统中如何使用这个模式。 Related patterns(相关模式) 列出相关模式及主要差别
第1章J2EE设计模式 介绍本书提到的模式之前,先要简单介绍设计模式的好处及其如何帮助解决问题 设计模式如何帮助解决问题 了解模式之后,下面看看设计模式如何帮助解决问题。 设计模式可以帮助进行软件设计和更好地设计软件。 一般来说,设计模式可以帮助我们解决应用程序设计阶段遇到的大多数常见问题,包括: 标识 组件内部结构及组件之间的关系 确定组件粒度及适当交互 定义组件接口 J2EE平台设计模式解决使用J2EE服务与技术的常见设计问题,包括 请求处理 ·服务定位与激活 远程通信与层间通信 组件选择 持久状态、事务与安全性管理 ·EIS集成 设计模式还可以帮助我们进行设计: 更适合于复用 更壮实,便于今后修改 J2EE应用程序是由组件构成的,放在客户层、Web组件层和业务逻辑(EJB)层。Java 言开发的组件釆用面向对象方法。设计这类应用程序时,建筑师要面对不同问题:如何标 只组件、选择组件类型和标识组件的内部结构(如作为组件建筑块的对象)。确定正确的抽 象层、粒度与灵活性是很困难的,需要有足够的经验 这时软件开发方法不一定能帮上忙。尽管可以用不同方法标识与分析模型对象,但通 常不是显式针对设计模型组件与对象的。实际开发还显示,应用程序中的组作不一定直接模 拟实际对象,但分析模型中通常根据实际对象定义对象。 因此,要选择]2EE提供的适当组件类型并不容易,特别是在选择不明显时,有时还要 考虑性能与安全要求。Web组件也是这样,可能要选择JSP( Java Server Pages)或小服务 以及业务逻辑层组件,首先要选择不同类型的EJB(无状态会话、状态会话、实体和消息驱 动bean)以及选择 CORBA'iRMI-IIOP分布式对象和JMS。这个决策会产生长远的影响。 采用设计模式时,可以得到这些决策的准则。下面是设计模式的另一些好处: ·帮助我们进行适当抽象 ·帮助我们进行适当一般化 ·帮助我们确定攴持复用的适当粒度 ·帮助我们提高设计火活性,更妤地适应将来的改变
