J2EE项目实训UML及设计模式——第7章 架构设计中的架构模式（第1部分）

1、杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料第7章 架构设计中的架构模式（第1/4部分）软件系统设计的一个核心问题是能否使用重复的体系架构，因为在软件系统的设计中，设计人员不仅需要追求类代码级别的程序方面的重用，也希望能够达到系统在体系架构级的软件重用，从而可以实现在不同的软件系统中使用同一体系架构以简化系统的总体设计。而系统地学习和掌握在软件体系架构设计中的一些常见的设计模式、并灵活和合理地应用这些架构模式是获得在体系架构这一层次软件重用的主要技术手段。本章则主要探讨在软件系统设计中与架构模式相关的设计思想、原则和方法等内容，这主要包括层模式及应用、mvc架构模式及应用、控制器模

2、式及应用、门面模式及应用等方面的内容。相信读者学习完本章的内容，会对软件系统的总体设计获得一个本质性的能力的提升。1.1 架构模式和设计模式1、软件体系架构及架构模式（1）软件体系架构产生背景早期软件系统开发中,开发者一般是把软件系统设计的重点放在数据结构和对算法的选择上，如donald e. knuth在其历史性经典巨著the art of computer programming所提出的关于程序结构的描述“程序数据结构+算法”。也能够说明当时的开发思路；而对于一个大规模的复杂软件系统来说，软件体系架构比起对程序的算法和数据结构的选择来说现在已经变得明显重要得多。 此时软件系统的开发者开始认

3、识到软件体系架构的重要，如rational公司提出了“以架构为中心”的统一软件开发过程(rup)。（2）软件系统设计的核心问题能否使用重复的体系架构也就是能否达到体系架构级的软件重用，从而可以实现在不同的软件系统中使用同一体系架构。（3）软件体系架构模式的产生基于这个目的，许多学者们开始研究和实践软件体系架构的模式问题。各种架构模式和代码模式越来越被广泛地应用在各种不同的软件系统的设计和开发实现中。因为软件开发过程中的一个永恒的主题是“软件复用”。而软件复用一般可以分为三个不同的层次，最低层次的软件复用技术其实也就是代码级复用（以类作为基本的复用单元），这主要是由支持面向对象编程技术的各种语言

4、来提供支持的，例如编程人员可以在java语言中应用继承、聚合、多态等特性来达到类级别的代码复用；第二个层次，则是系统中的功能组件级别的复用，编程人员一般可以通过应用各种设计模式来达到这样的目标；最高层次的复用则是系统体系架构级的复用，如mvc架构模式、前端控制器模式等。2、什么是设计模式设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计方面的经验总结。使用设计模式的主要目的是为了能够更好地获得可重用性，这包括体系结构和实现代码等方面，并能够让所开发出的软件系统更容易被他人理解、同时也保证系统的体系结构的正确性和代码的可靠性。3、利用设计模式来进行软件系统开发所体现出的主要优点（1

5、）不必做重复劳动，因为模式是一种指导在一个良好的指导下（包括解决某种问题的思想和方法），会得到解决问题的最佳办法包括系统架构和实现代码。开发软件系统时能够少走弯路，同时所开发出来的软件也能更加可扩展和可重用，从而可以提供更强的可维护性、更短的开发周期。因为模式是一种经验的积累和总结，所以通过模式，我们可以站在巨人的肩膀上去思考问题、解决问题，熟练使用设计模式可以提高软件系统的开发者的工作效率、改善软件产品的质量，最终带来经济效益。比如下面所罗列出的是在一般的软件系统的开发过程中都会面临到的一些问题：1) 如何充分利用容器管理事务、持久性和安全性2) 把会话数据存放在哪里？是由表示层地组件负责数

6、据验证还是由业务层组件来负责？3) 如何定义系统中地各个业务实体组件之间的关系？各层之间如何传送参数？4) 如何减少对远程系统中的方法调用的次数？以及如何集成现有应用系统程序？这些问题是软件系统的开发者都会碰到的，而设计模式（gof设计模式和j2ee核心架构设计模式）能够更好地帮助开发者解决这些问题。另外在分布式企业应用系统的开发中，由于需要涉及对多种不同的技术的具体应用，这将对设计和编程开发人员提出了更高的要求。在此种形式的系统开发实践中，如果能够运用一些比较成熟的设计模式，不仅可以得到可复用的设计方案，同时也能够降低项目的技术风险。（2）用模式的思想来设计系统可以获得系统设计方面的灵感使得

7、自己的系统更具有安全性、灵活性和可维护性在模式中所提到的每一点都能为开发者在更短的生命周期中开发出更多、更好的应用系统；反过来说，如果开发者没有系统地应用模式的各种指导思想来指导系统设计工作，那很可能就会在设计系统时出现漏洞和设计不周密的情况。（3）正确使用设计模式是软件系统的设计人员必须掌握的基本技能因此对于任何想开发出灵活高效、健壮的软件产品的开发者特别是系统的设计人员，熟练掌握并正确使用设计模式都是必须掌握的基本技能。（4）应用设计模式时所应该注意的要点l 模式有不同的领域和应用的场景设计模式也不是万能的，只针对某种场景下的问题提供了解决方案和实现的示例代码。因此，在应用某个设计模式来解

8、决软件系统中的问题时，需要考虑应该应用哪种形式的模式。l 合理地应用设计模式在软件设计过程中，应当正确对待产品需求与设计模式之间的关系：是产品需求引出设计模式，而不是设计模式决定产品需求。否则就会出现“技术至上论”，因为满足用户的需要是开发者首先要考虑的问题。l 不要为了设计模式而乱用设计模式通过系统地学习和了解设计模式，将使开发者对系统的设计中所涉及的架构和实现代码会有更深地理解。在应用开发过程中，如果遵循和应用了模式的规则，将能够使开发者所设计出的系统包括架构和编程实现的代码更便于理解，易于交流；但设计模式的应用应该是合理地应用，应该充分地了解系统中所要解决问题的场景是否与所要应用的某种模

9、式的应用场景相一致、应用该模式后能够为软件系统或者开发工作带来什么优点（可维护性、可复用性等方面），否则将得不偿失！更不应该为了设计模式而乱用设计模式！4、设计模式的分类由于软件系统的开发过程涉及多种不同的层次，比如有系统架构、代码实现和软件系统的测试等方面。因此，设计模式根据应用的目的不同，也可分为多种不同的类型。但一般从设计模式所涉及的解决问题的层次性，分为如下三种层次：（1）系统架构模式（如j2ee核心模式中的各种架构模式）（2）通用职责分配软件模式（grasp模式-general responsibility assignment software patterns ）（3）代码设计模

10、式（如gof的23种代码设计模式）gamma、helm、johnson和vissides（简称为gof）在其中文版设计模式：可复用面向对象软件基础（机械工业出版社，2000年9月）中所提出的23种设计模式。5、架构模式架构模式一般着眼于不同业务系统中共性问题的解决方案的设计，是有关大尺度和粗粒度的设计方案的重用；它主要描述软件系统中的程序的基本结构组织或纲要，通常提供一组事先定义好的子系统，并指定它们的责任，同时给出把它们组织在一起的法则和指南。一个架构模式常常可以分解成多个不同的模块组件的设计模式的联合使用，同时架构模式中所定义的系统架构的好坏将会直接影响到应用系统本身的总体布局和系统的总体

11、性能的改善。合理和灵活地应用各种相关的架构模式，是设计出高质量的应用系统的重要保证。6、grasp模式（通用职责分配软件模式 ）它能够帮助软件系统的开发者把握基本的对象设计技术，并且用一种系统的、可推理的、可说明的方式来应用面向对象技术中的各种设计理论和思想、原则，并指导软件系统的设计人员正确地进行类的职责的分配和类之间关系的决定；另外，通用职责分配软件模式也是学习使用gof 代码设计模式的基础。有关对通用职责分配软件模式的细节内容的学习，请读者参考本书的第八章“通用职责分配软件模式（grasp）”的章节。7、gof（gang of four）代码设计模式（1）gof代码设计模式主要着眼于通用

12、原理和相同场景时的编程实现gof代码设计模式一般是有关中小尺度的对象编程方法的重用，主要是用来处理和解决程序模块设计和编程实现中反复出现的一些共性的场景问题。例如，gof在设计模式-可复用面向对象软件的基础一书中所总结出的23种基本的设计模式。gof的23种设计模式的分类，主要分为创建型：5种、结构型：7种、行为型：11种。（2）正确地区分grasp模式和gof代码设计模式的不同。1) 应用目的：grasp指导如何进行类的职责分配，而gof指导如何进行代码优化。2) 应用场合：grasp适用于类的分析和设计阶段，而gof适用于类的编程实现阶段。有关对gof代码设计模式的细节内容的学习，请读者参

13、考本书的第十章“典型gof设计模式及应用”的章节。8、架构和模式两者最主要的不同（1）架构(architecture)更加关注的是所谓的“高层设计”（high-level design）架构是一组有关如何决定软件系统的组织结构的重要决策，以及接口和它们相互协作的行为的选择。（2）而模式(pattern)关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用因为当软件系统的分析和设计人员在不同的层面上考虑问题的时候，就形成了解决不同问题域上的模式（pattern）；同时模式的共同目标是把问题中的“不变部分”和“变化部分”分离出来。而其中的不变的部分，就构成了模式。因此，模式是一个经验提取的

14、“准则”，并且在一次一次的实践中得到反复地验证。9、如何学习和掌握设计模式（1）学习并最终掌握设计模式是成为一个高级软件设计师的必由之路但由于设计模式是一种方法论的抽象，应该建立在经验的基础上。读者刚开始学习设计模式时，可能会感觉到一定的困难、并且觉的比较抽象和难懂。（2）要理解处理问题的思想、方法和技巧，而不用死记代码本身因为设计模式是前人经验的总结，我们不要死记各个模式的名词和具体的实现代码，而应该要理解处理问题的技巧和思想，要把设计模式与实际的软件系统的开发相互结合在一起。（3）学习设计模式的一般过程首先系统地学习软件系统中常用的各种架构模式（比如j2ee core pattern），其

15、次再学习通用职责分配软件模式（grasp模式），最后再学习代码设计模式（gof的23种设计模式）。1.2 架构设计中的层模式及应用1.2.1 层架构模式的典型应用1、软件系统中的层（layer）软件系统中的层是一个大尺度的元素，通常是由一些系统包或者子系统（如组件）组装而成的。层这个概念在计算机领域是非常普遍的一个概念，因为计算机系统本身就体现了一种层的概念：系统调用层、设备驱动层、操作系统层、cpu指令集。同时每个层都负责自己的职责，而各个层之间是相互隔离的。网络系统中同样也存在和应用了分层技术，最著名的tcp/ip的七层协议。因此，相信读者对层和分层等方面的基本概念应该是不陌生的。2、应用

16、层体系架构模式（layers architecture pattern）进行系统设计（1）层体系架构模式所谓的层体系架构模式，其实就是把应用系统中的各个部分分解成各个不同的子任务组或者子系统，而其中的每个子任务组又都各自处于一个特定的抽象层次上，每个子任务组彼此之间是相互隔离的、但每个层本身则是职责内聚的。层体系架构模式是与系统的逻辑架构相关的、并经常地被应用在系统的架构设计中。也就是说，它只描述了系统设计中的各个元素概念上的组织及关系，但它不是物理上的包或者具体的部署结果。（2）利用层架构模式来组织系统时能够构造出一个层次化的系统结构应用系统经过合理地分层和隔离，从而使得每一层都能够为其所对

17、应的上一层提供服务而成为服务的提供者，同时也作为下层的客户端而获得所需要的服务；由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，同时还遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。（3）利用层架构模式进行系统设计所能够达到的效果通过合理地应用层架构模式来进行系统设计，将允许系统的设计人员将复杂的系统中所涉及的各个方面的问题分解成一个层次的实现。由于在分层后的系统结构中，每一层最多只影响其相关联的上、下两层，同时只要给相邻的上、下层提供接口或者实现接口，从而也就能够允许每层使用

18、不同的方法包括不同的技术来实现，因此为软件的重用提供了强大的结构支持。将系统进行合理地分层的另一个好处是，这些层形成了应用系统开发小组的自然分界因为对每层的开发人员所需要的技巧是不同的、项目分工时可以根据人员的技术水平和对相关的层所涉及的技术熟练程度进行合理地任务分配。比如，用户界面层的开发小组人员需要了解将使用的用户界面工具和实现的相关的技术等；持久层的开发小组人员需要熟悉相关的数据库、持久工具等。3、层架构模式在j2ee平台系统开发中的应用（1）标准的三层架构的系统j2ee平台能提供多层分布式应用模型并能重用组件（这主要是由ejb组件技术来实现），同时也为用户提供统一的安全模型（声明式和编

19、程式的具体实现）和灵活的事务处理（声明式事务和编程式的事务具体实现）控制。martin fowler在patterns of enterprise application architecture一书中，将整个架构分为三个主要的层：表示层（presentation）、领域层（domain）和数据源层（data persistence）。（2）j2ee平台系统开发中常见的分层策略但是在实际的项目开发中，应用系统的设计人员通常会对标准的三层架构进行扩展以满足应用系统中的具体要求。一个最常见的扩展方式就是将三层体系架构扩展为五层体系架构，即将整个应用系统分离为表示层（presentation）、控制

20、层（controller）、业务逻辑层（business logic）、数据持久层（data persistence）和数据存储层（data source）。j2ee平台系统开发中这样的分层策略，其实是在标准的三层架构中增加了两个中间层控制层位于表示层和业务逻辑层之间、数据持久层位于业务逻辑层和基础的数据存储层之间。从上面的分层设计结果来看应用系统的架构时：由于系统中的各个部分被分离为不同的部分，并且在具体的实现方面各个层次中的组件是完全分离的，这样将能够使业务处理逻辑功能成为应用系统的中间功能服务（也就是中间层）。中间业务层的具体实现时，可以不依赖系统中具体的表示层技术，也不依赖于系统中具体

21、的数据层的技术实现。 多层架构倡导的显示功能、业务逻辑处理功能和数据访问功能完全分离，从而避免了在应用系统的需求发生变化时（功能方面或者非功能方面），而产生牵一发而动全身的连锁修改系统的设计方案和实现的代码，可以实现系统的松耦合和良好的系统可维护性。4、对层架构模式的优缺点分析（1）使用层架构模式的主要优点在构造应用系统时，架构设计师可以把整个系统想象成是由不同的“积木”块（在软件系统中的积木块，也就是各个功能组件）而构成的，这些“积木”块之间的关系一般体现为纵向的分层和横向的功能模块组件。系统的开发人员可以向系统中插入所需要的某个“积木”块以扩充其功能、或者替换掉其中的某个“积木”块而完善系

22、统的功能。在这种分层体系的结构中，应用系统都被表示为由一系列相关联的各层单独的子系统所构成，而每个层中的子系统又都采用组件技术来设计和构造，每个组件系统也可以对其上、下层中的组件进行调用。这种体系结构，最后将能够达到层的上层使用者只管使用所需要的目标层，而并不需要去了解该目标层的具体结构以及该目标层中的各个组件的具体技术实现细节；同时当应用系统的需求发生变化时，只需要改变某些基础层，但不会影响到其上层的应用实现。这主要是由于各个层之间是相互隔离的。在应用层架构模式时，设计人员应该制定出各层的接口标准，层与层之间进行关联时只通过接口进行连接，从而可以减少不同层之间的相互依赖。将系统划分成多层结构

23、的最大好处是提高了开发速度、增强系统的健壮性和稳定性、提高了系统的可维护性和拓展性，也能够大大节约系统开发成功后的维护、完善修改的成本。（2）使用层架构模式的主要缺点使用层架构模式不可能封装所有的功能，一旦有功能变动，势必要波及到各个关联的层（一般为其上、下两层）。为了尽可能地减少这样的影响，设计人员一定要通过接口进行连接；另外在数据传送方面将会体现出低效，比如在j2ee的多层架构的系统中，如果要实现在数据访问层中将某个数据对象传送到表示层，将要“穿透”相关的许多层。1.2.2 层模式的应用及系统分层设计策略1、非分层架构设计时对应用系统所可能带来的问题（1）整个系统是一个高度藕合的系统由于系

24、统中的许多部分高度地耦合和相互关联，因此应用系统中某个功能模块的需求一旦发生变化时，将会波及到整个系统中的各个关联的不同部分都会被动地进行修改。（2）降低了系统的可重用性由于整个应用系统中的各个功能模块是相互组合在一起的，特别是系统中的核心应用逻辑的功能具体实现与用户访问接口的表示层的具体实现技术捆绑在一起。当然这些应用逻辑在其它不同的表示层的接口上将无法被重用，导致“拔出萝卜带出泥”的结果。另外还由于潜在的通用技术服务（如数据库访问的事务、系统的安全验证、对象缓存、日志记录等）或业务逻辑，与更具体的应用逻辑捆绑在一起，因此这些通用的技术服务或者业务逻辑功能的实现也将面临着无法被重用。（3）不

25、便于系统的模块划分和人员分工由于系统的不同功能模块是高度地关联和耦合，因此难以对应用系统中不同的开发者清晰界定各个模块的工作界限、功能实现的要求和人员分工；同时由于高度耦合的系统中一定会混合了系统的各个方面的功能模块，因此在改进应用系统的具体功能的实现时，特别是在扩展系统功能以及希望能够应用新技术时将会付出更大的代价。2、如何解决上面所提及的各个问题对上面所提及的“非分层架构设计时对应用系统所可能带来的问题”解决的具体方案是采用层架构模式，并且基于下面的分层设计策略实现。当然，在层模式的系统架构设计工作中最难的一个问题，还是一个具体的应用系统到底应该分为几层、每个层中都应该提供那些功能组件，以

26、及每个组件中的各个类要承担什么方面的职责等方面的问题的解决。（1）系统分层时应该遵守“高内聚、低藕合”的职责设计原则一般，可以把应用系统中的“粗粒度的逻辑结构”组织到不同的层中，每一层都具有独立和相关的职责，使得较低的层成为低级和通用的服务，较高的层将能够获得更多的不同服务。比如，将应用系统中所有涉及与数据持久化相关的功能实现（这包括数据库访问、xml解析、文件io等）都合并入到系统的持久层中，而将系统中的所有的输入、输出相关的功能实现都并入到表示层中，而与领域业务相关的功能逻辑都归纳到系统中的业务处理层。系统经过这样的初步分层后，问题的复杂性将会被降低、同时相关所要解决的技术难题也将分散到不

27、同的层面中，并委托不同的技术特长的开发人员来解决；再进一步地对该分层设计进行优化和根据系统中的具体性能的要求、项目以后的可能变化因素，再进一步地细分。（2）各个层之间进行关联时应该遵守“面向接口编程实现”的设计原则由于应用系统被分离为不同的层，因此各个层必须相互组合和协作才能构成整个应用系统的功能要求，这样将不可避免地要考虑层之间如何进行关联的问题。所应该把握的是要达到从较高的层到较低的层进行协作和耦合（高层应该依赖下层），避免从底层到高层的耦合。应用系统的健壮性、灵活性、可重用性、可升级性和可维护性，在很大程度上取决于应用系统中的分层策略和各层之间的关联的设计。层之间应该通过接口实施联接，也

28、就是遵守“面向接口编程实现”的设计原则。（3）通过系统架构模式和代码设计模式对分层策略进行优化当对系统的分层设计产生出了实现方案时，再应用系统架构模式来规范系统中的分层实现。而对层内的各个组件、层与层之间的关联等的具体实现，则可以运用代码设计模式进行简化功能实现。3、应用层架构模式时如何实现各层之间的关联如何实现系统中各层之间的关联和协作？当然，我们的设计目标应该是达到“高内聚、低藕合”的设计效果。在系统的架构设计上，通常可以利用门面（外观）、控制器、中介等架构模式来实现系统设计中的层与层之间的相互关联和协作。1.2.3 利用系统架构模式对系统分层设计进行优化1、利用门面（外观）架构模式实现各

29、层之间的关联和协作（1）常规的“多对多”的连接形式在应用系统的分层设计中经常会出现一种应用的场景，在某一层中的各个组件需要访问另一层中的不同功能组件以获得不同的功能服务。从而导致层与层之间的关联关系出现“多对多”的连接形式，请见下面的图7.1中所示的访问状态。图7.1 客户层和子系统层之间的“多对多”的关系示图比如，在系统业务处理层中的不同业务功能模块（它为门面架构模式中的“客户层”）都需要利用系统持久层（它为门面架构模式中的“子系统”）中的不同数据访问组件（dao）进行数据库数据的访问，在系统的控制调度层中的各个业务控制组件（servlet组件或者struts框架的action组件，它们为门

30、面架构模式中的“客户层”）也都需要访问系统业务处理层（它为门面架构模式中的“子系统”）中的不同业务功能组件，所有这样的问题都可以应用门面（外观）架构模式来优化。（2）利用门面架构模式分离复杂的“多对多”的关联形式下面的图7.2给出了利用门面（外观）架构模式实现各层之间的关联和协作的原理示图，在此种形式的系统架构中，通过门面组件能够隔离客户层和子系统本身之间的紧密藕合关系。将原来图7.1中所示的客户层和子系统层之间的“多对多”的紧密关系分离为两个“一对多”的松散藕合关系。图7.2 利用门面架构模式实现各层之间的关联和协作的原理示图2、门面架构模式在网上商城项目中的具体应用示例在网上商城项目的系统

31、架构中，由于希望能够达到彻底地隔离业务处理层和系统的持久层之间的关系，从而使得业务逻辑组件有更好地重用性。在业务处理层和系统的持久层之间添加了一个数据访问服务层，并提供数据访问服务（dao服务）组件。该dao服务组件其实就是网上商城系统中的持久层的门面组件。下面的图7.3所示为网上商城项目的系统架构示图，并请注意其中的黑体部分的描述文字。图7.3 网上商城项目的系统架构示图当然，为了将项目中的表示层和系统中的业务处理层之间的关系也希望能够隔离开，比如考虑到应用系统以后将可能需要面对其它形式的表示层的客户端的设备（如手机、应用程序的桌面客户端等）在具体的系统架构时也可以应用“业务外观组件”。同样

32、也请见图7.3所示的系统分层架构示图。下面的图7.4所示为网上商城项目中的dao服务层和系统的持久层之间的类图。图7.4 网上商城项目中的dao服务层和系统的持久层之间的类图3、利用控制器模式实现“表示层”和“模型层”之间的关联和协作在很多表示层的框架系统中的架构设计中，都应用了控制器模式来实现“表示层”和“模型层”之间的关联和协作。其中的控制器组件一般都设计为前端控制器和业务调度控制器两种不同的形式。下面的图7.5所示为控制器模式的工作原理示图。控制调度层表示层中的请求业务处理层表示层中的业务成功显示数据访问层表示层中的业务失败显示前端控制器业务调度控制器图7.5 利用控制器模式实现“表示层

33、”和“模型层”之间的关联和协作利用控制器模式进行系统分层和架构的典型应用示例是apache struts框架，在struts框架中的控制层组件是由一个前端控制器actionservlet组件和相关的多个不同的后端业务控制器action类组件所构成的。下面的图7.6所示，为struts框架中的各个层中的组件的架构示图，从图中可以看到，经过控制器模式中的各个控制器组件的隔离后，将表示层组件中的各个jsp页面和模型层组件中的各个业务功能组件类之间分离开。图7.6 控制器模式在struts框架中的具体应用示图4、利用中介架构模式实现用一个中介对象把一系列的对象交互封装（1）利用中介架构模式可以降低系统

34、的复杂性和提高可扩展性由于类之间存在“多对多”的关系（每个对象所在的层也将紧密藕合），从而导致各个类之间的交互操作非常多，同时每个类的行为操作都依赖于彼此对方。这样的设计后果将是这样的状况：修改其中的一个类的行为，会同时涉及到修改很多其它类的行为。从而降低这些对象之间的耦合性、也为系统的后期维护和完善带来隐患。在生活中的各个“购车者”在购买汽车时将分别都要与“公安局交通队”、“汽车销售商”和“商业银行”等方面的人员进行交互。如果从类的设计的角度来，购车者类与其它的各个类之间的关系请见下面的图7.7所示。图7.7 购车者类与其它的各个类之间的关系这样的后果一方面将会增加购车者在购买过程中的活动次

35、数（分别要访问公安局交通队、汽车销售商和商业银行以获得商业贷款），同时也会使得每个购车者都要重复进行这样相同的行为。从整个系统的总体的全局的角度来看时，系统中的各个组件之间的交互关系将会很复杂，同时系统的藕合性也是紧密的关联关系。对此，可以应用中介架构模式中的中介组件来隔离各个部分。对图7.7中所示的问题，应用中介架构模式设计后的结果请见下面的图7.8所示，中介架构模式从分层的效果来看是比较好的分层策略。这样分离后的各个购车者只需关心和中介（mediator）的关系，使“多对多”的关系变成了两个“一对多”的关系，从而可以降低系统的复杂性，提高可修改扩展性。所应该注意的是，中介架构模式从应用目的

36、方面与前面所描述的“门面模式”有一定的相似之处。但是它们两者有如下方面的不同。（2）中介架构模式和门面架构模式在应用的场合方面是不同的门面模式是介于客户端程序与子系统之间的，而中介者模式是介于子系统与子系统之间的。图7.8 应用中介架构模式降低对象之间的耦合性（3）中介架构模式和门面架构模式在应用的目的方面是不同的应用门面模式是希望将系统中原有的复杂业务逻辑提取到一个统一的接口，简化客户端的访问者对后端各个服务的提供者逻辑的使用。它是被客户所感知的，而原有的复杂业务逻辑则被隐藏了起来。而大多中介者角色对于子系统中的另一个子系统程序却是透明的。（4）中介架构和门面架构模式在后端的服务提供者的各个

37、组件之间的关系方面也是不同的门面模式中的后端的服务提供者之间是可以相互关联的（请见图7.2中的各个组件之间是允许交互的）；而在中介者模式中，则是断绝后端的服务提供者（各个同事类）之间的直接交互（比如在图7.7所示中的“汽车销售商”此时也不再与“商业银行”进行直接交互，它们之间也通过中介者组件来实现交互）。1.2.4 如何实现层之间的松散耦合的关联1、了解和描述出系统中的层与层之间和包与包之间的耦合关系可以用依赖关系表达耦合，因此只需要画出系统的架构包图，并观察架构包图中的各个包之间的依赖关系就可以了解系统中的各个层之间的耦合关系。对产生紧密藕合关系的各个包需要进行分离，从而也就达到层与层之间的“松散的分层”设计目标。在图3.11中示例了网上商城项目中的系统架构包图，通过该架构包图可以了解系统中的各个层之间的耦合关系，其中的表示层只与系统中的控制层发生关联；而控制层与系统中的业务处理层之间也发生关联，因为控制层是表示层和业务处理层之间的“中介”；而业务处理层则依赖于系统的持久层中所提供的数据访问服务。本项目的系统架构遵循了j2ee平台的系统开发中两个主要的原则：“多层架构、松藕合”，同时系统通过应用三大框架（strutsspringhibernate），应用系统中的各个组件模块功能相互独立封装，层与层之间关联少、并