（计算机软件与理论专业论文）松耦合在人事系统开发设计中的应用.pdf

中文摘要 随着计算机技术特别是网络技术的发展，软件业面临的环境更加复杂，竞争 同益激烈，为了在激烈的竞争中保持优势，要求软件具有良好的性能，这些性能 包括：可升级性、可靠性、可用性、可扩展性、可维护性、可管理性、安全性。 软件系统的松耦合性是衡量系统内部的层次与层次之间，模块与模块之间的依赖 程度的标准之一。软件系统的耦合性包括横向的耦合和纵向的耦合，横向的耦合 通常体现在系统的各个模块、类之间的关系，而纵向的耦合，体现在系统的各个 层次之间的关系。在软件设计过程中，特别是软件框架的设计过程中，降低软件系 统的耦合性是改善软件系统的可维护性，可理解性，可扩展性的关键。在软件体系 架构设计中，分层式结构是最常见，也是最重要的一种结构。分层从逻辑上将子 系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限 制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。分层式 结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层( 又或称为业务 层) 、表示层。在业务复杂的情况下，三层的基础架构不能满足我们需求的时候， 把三层中的某一层再细分为两层或更多层，对象关系映射( o b j e c tr e l a t i o n a l m a p p i n g ，简称o r m a p p i n g ) 技术是一种把数据逻辑处理层同数据层分离的技术。 分层技术是解决系统的松耦合性的非常重要的技术之一，但分层技术本身也有缺 陷，为了解决分层带来的缺陷，利用x m l 技术和元数据技术实现了数据库字段同 数据库表的松耦合性，解决了分层引起的级联删除问题。把系统中的公用模块的 功能以w i n d o w s 服务来实现，解决了分层带来的第二个缺陷：分层太多会影响到 系统的性能。利用分层技术和o r m a p p i n g 技术从纵向上实现了系统的松耦合性。 模块之间的松耦合性也是影响系统松耦合性的一个重要因素，在设计过程中使用 设计模式可以降低模块之间的耦合程度，设计模式使用抽象耦合和分层技术来提 高系统的松散耦合度。典型的实现系统松耦合的设计模式有：抽象工厂模式 ( a b s t r a c tf a c t o r y ) 、命令( c o m m a n d ) 模式、观察( o b s e r v e r ) 模式、外观( f a ! ；a d e ) 模式等等。利用设计模式从横向上实现了系统的松耦合性。本文首先分析了如何 利用分层技术和o r m a p p i n g 技术来实现系统架构的松耦合性，接着分析了解决分 层技术的两个缺陷的方法。最后分析了如何通过运用设计模式来实现模块之间的 松耦合性。通过以上的理论研究，本文结合一个具体的软件系统验证了理论研究 的正确性，介绍了该系统的整体框架，如何实现数据库结构的松耦合性和该系统 中的w i n d o w s 服务。并对其中的不足及应该改进的方面作了一定程度的分析。 关键词：松耦合性；架构；模式；x m l 技术；w i n d o w s 服务 分类号：t c p 3 0 1 a b s t r a c t a st h ec o m p u t e rt e c h n o l o g yd e v e l o p s f a s t ，e s p e c i a l l yt h en e t w o r kt e c h n o l o g y ， s o f t w a r ei n d u s t r yc o m p e t e si n t e n s e l y i tr e q u i r e ss o f t w a r et oh a v ea g o o dp e r f o r m a n c e t h ep e r f o r m a n c ei n c l u d e sm a i n t a i n a b i l i t y , e x t e n s i o n ，s e c u r i t ya n ds oo n s o f t w a r e s l o o s ec o u p l i n gi so n eo ft h es t a n d a r d sf o rm e a s u r i n gt h ed e p e n d e n c eb e t w e e nl a y e r sa n d m o d u l e s i nt h ed e s i g no fs o f t w a r ee s p e c i a l l yi nt h ed e s i g no ff r a m e ，r e d u c i n gt h el o o s e c o u p l i n go fs o f t w a r ei sa d v a n t a g e o u st oi m p r o v et h ep e r f o r m a n c eo fs o f t w a r e l a y e r t e c h n o l o g yi s o n eo ft h ec o m m o na n di m p o r t a n tt e c h n o l o g i e sf o rr e d u c i n gt h e s o f t w a r e sl o o s ec o u p l i n g u s i n gt h el a y e rt e c h n o l o g y ，p e o p l ec a nl i m i tt h ed e p e n d e n c e b e t w e e ns u b s y s t e m sa n dm a k et h es y s t e mm o r el o o s ec o u p l i n g o n es y s t e mc a l l g e n e r a l l yb ed i v i d e di n t ot h r e el a y e r s ：v i e w e r , c o n t r o l l e r , a n dm o d u l e i nac o m p l e x c o n d i t i o n ，t h r e el a y e r sc a n n o ts a t i s f yt h er e q u i r e m e n ta n dt h es y s t e mc a nb et h e n d i v i d e di n t om o r el a y e r s o - r m a p p i n gt e c h n o l o g yi so n eo ft h et e c h n o l o g i e sw h i c hc a n d i v i d et h em o d u l ei n t ot w ol a y e r s ：d a t al a y e ra n dd a t ap r o c e s s i n gl a y e r a l t h o u g hl a y e r t e c h n o l o g yi sai m p o r t a n tt e c h n o l o g yf o rs y s t e m sl o o s ec o u p l i n g ，i th a st w of l a w s m a k i n gt h ed a t a b a s ef i e l dl o o s i n gf r o md a t a b a s et a b l eu s i n gx m lt e c h n o l o g ya n d d y n a m i cc o m p i l et e c h n o l o g yi so n eo ft h es o l u t i o n st ot h ef i r s tf l o wo fl a y e rt e c h n o l o g y u s i n gw i n d o w ss e r v i c ei so n eo ft h es o l u t i o n st oa n o t h e rf l o wo fl a y e r t h el o o s e c o u p l i n gb e t w e e nm o d u l e si so n eo ft h ei m p o r t a n tk e y sf o rs o f t w a r e sl o o s ec o u p l i n g u s i n gd e s i g n e dp a t t e r nc a nr e d u c et h el o o s ec o u p l i n go fs o f t w a r e t h et y p i c a l l yp a t t e r n d e s i g n e df o rr e a l i z i n gt h es o f t w a r e sl o o s ec o u p l i n gi so b s e r v e rp a t t e r n ，f a c a d ep a r e r n ， a b s t r a c tf a c t o r yp a r e r na n dc o m m a n dp a t t e r n i nt h ea r t i c l et h ea u t h o rf i r s tr e s e a r c h e d t h el a y e ra n do r m a p p i n gt e c h n o l o g ya n ds e c o n d l y ，t h ex m lt e c h n o l o g ya n dw i n d o w s s e r v i c e a tl a s tt h ea u t h o rr e s e a r c h e dt h ed e s i g n e dp a t t e r n t h ea u t h o rc o n f i r m e dt h e a c c u r a c yo ft h et h e o r yt h r o u g hah u m a ns y s t e m k e y w o r d s ：l o o s i n gc o u p l i n g ；f l a m e ；p a t t e r n ；x m lt e c h n o l o g y ；w i n d o w ss e r v i c e c l a s s n 0 ：t c p 3 0 1 学位论文版权使用授权书 本学位论文作者完全了解北京交通大学有关保留、使用学直论文的规定。特 授权北京交通大学可以将学位论文的全部或部分内容编入有关数据库进行检索， 并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校向国 家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 本学位论文保密，三年内不得公开发表。 学位论文作者签名： 面l 己轧 签字日期：钿6 年，z 月f 日 刷雠：纱包罨 签字日期：2 伽占年即日 致谢 本论文的工作是在我的导师白建军高工、田盛丰教授的悉心指导下完成的， 白建军高工和阳盛丰教授严谨的治学态度和科学的工作方法给了我极大的帮助和 影响。在此衷心感谢三年来自建军和田盛丰老师对我的关心和指导。 康j i i 高工悉心指导我们完成了实验室的科研工作，在学习上和生活上都给予 了我很大的关心和帮助，在此向康川老师表示衷心的谢意。 刘成高工对于我的科研工作和论文都提出了许多的宝贵意见，在此表示衷心 的感谢。 在实验室工作及撰写论文期间，熊飞、朱平等同学对我论文中的软件系统的 松耦合性研究工作给予了热情帮助，在此向他们表达我的感激之情。 另外也感谢家人，他们的理解和支持使我能够在学校专心完成我的学业。 1 绪论 1 1研究的背景和意义 1 1 1 软件系统开发的新需求 随着计算机技术特别是网络技术的发展，软件业面临的环境更加复杂，竞争 日益激烈，变化更难以预测，为了在激烈的竞争中保持优势，要求软件具有良好 的性能，这些性能包括：可升级性、可靠性、可用性、可扩展性、可维护性、可 管理性和安全性等。性能是指系统提供的功能要满足一定的性能衡量标准，这些 标准可能包括系统反应时间以及处理交易量的能力等。可升级性是指当系统负荷 加大时，能够确保所需的服务质量，而不需要更改整个系统的架构；可靠性是指 确保各应用及其相关的所有交易的完整性和一致性的能力；可用性是指一个系统 应确保一项服务或者资源永远都可以被访问到；可扩展性是指在不影响现有系统 功能的基础上，为系统添加新的功能或修改现有功能的能力；可维护性是指在不 影响系统其他部分的情况下修正现有功能中问题或缺陷，并对整个系统进行维护 的能力；可管理性是指管理系统以确保系统的可升级性、可靠性、可用性和安全 性的能力；安全性是指确保系统安全不会被危及的能力。 性能 通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能；也可以 通过系统能够处理的交易量( 每秒) 来衡量系统的性能。无论采取哪种衡量系统性 能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该 是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而 不是系统设计开发人员应该关注的事情。 可升级性 可升级性是指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更 改整个系统的架构。当系统中负荷增大时，如果系统的响应时间仍能够在可接受 的限度内，那么就可以认为这个系统是具有可升级性的。要想理解可升级性，必 须先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同 时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已 经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。 要想升级已达到最大负载能力的系统，必须增加新的硬件。新添加的硬件可以以 垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。 水平升级包括在环境中添置新的机器，从而增加系统的整体处理能力。 可靠性 可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系 统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够像负荷未增加 以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。 如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可 升级性。因此，一个真正可升级的系统必须是可靠的系统，在构建系统架构时， 可靠性也是必须着重考虑的问题。 可用性 可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。可靠 性可以增加系统的整体可用性，即使系统部件出错，却不会影响系统的可用性。 通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件的错误会对系 统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统仍然可用。 可扩展性 可扩展性是指在不影响现有系统功能的基础上，为系统添加新的功能或修改 现有功能的能力。当系统刚配置好的时候，很难衡量它的可扩展性，直到第一次 必须去扩展系统已有功能的时候，才能真正去衡量和检测整个系统的可扩展性。 任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该 考虑下面几个要素：低耦合、界面( i n t e r f a c e s ) 和封装等。 可维护性 可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺 陷的能力。同系统的可扩展性相同，当系统刚被部署时，很难判断一个系统是否 已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护 性，必须考虑下面几个要素：低耦合、模块性和系统文档记录等。 耦合性是模块独立性的度量之一。耦合性是模块间相互依赖程度的度量，耦 2 合的强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接 口的数据。耦合性越高，模块独立性越弱。软件系统的耦合性包括横向的耦合和 纵向的耦合，横向的耦合通常体现在系统的各个模块、类之间的关系，而纵向的 耦合，体现在系统的各个层次之间的关系。软件系统的松耦合性是衡量系统内部 的层次与层次之间，模块与模块之间的依赖程度的标准之一。一个系统的松耦合 性有利于提高系统的稳定性、可维护性、可扩展性和可升级性。它是保证软件质 量的基础。在软件设计过程中，特别是软件框架的设计过程中，降低软件系统的耦 合性是改善软件系统的可维护性、可理解性和可扩展性的关键 1 1 2 目前软件系统的缺陷 就目前软件开发的水平来说，还不能完全达到系统松耦合性的要求。现有的 大部分软件系统还存在着一些缺陷： 软件的稳定性 软件的稳定性从软件开发的角度出发，强调软件架构的稳定，即需求、代码 等的变更对软件系统的影响尽可能地小，这也是架构设计要解决的首要任务。其 次是功能模块之间的耦合程度，模块间的紧耦合性往往是影响系统稳定性的主要 因素。 软件的可维护性 软件生存周期每个阶段的工作都与软件的可维护性有密切的关系，实际上， 软件的可维护性是软件开发各个阶段的关键目标。在设计系统的软件结构和模块 时，要充分运用结构化和模块化技术，减小模块的耦合性、提高模块的内聚性， 获得较高的模块独立性。这都是影响可维护性的基本要素。 软件的可扩展性 要想使系统有利于将来的扩展，就要求系统有一个松耦合的架构和松耦合的 功能模块设计。 软件的可升级性 软件的可升级性是指在原有的功能的基础上增加一些新的功能，更进一步提 3 升软件的性能和扩展软件的功能。对于可以升级的软件来说，要求其具有重构性。 实现软件系统的松耦合性是提升软件稳定性、灵活性、通用性和可维护性的 方式之一。 1 2论文研究内容 本论文针对目前软件开发系统的现状、需求和项目实际情况的需要，对软件 系统的松耦合性进行了研究，并通过一个实际的系统验证了研究理论的正确性。 研究的主要内容包括： 在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。分 层从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通 过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易 于维护。分层可以从纵向来实现软件系统的松耦合性。分层式结构一般分为三层， 从下至上分别为：数据访问层、业务逻辑层( 又或称为业务层) 、表示层。在业 务复杂的情况下，三层的基础架构不能满足我们需求的时候，把三层中的某一层 再细分为两层或更多层，对象关系映射( o b j e c tr e l a t i o n a lm a p p i n g ，简称 0 r m a p p i n g ) 技术是一种把数据逻辑处理层同数据层分离的技术。分层技术是解 决系统的松耦合性的非常重要的技术之一，但分层技术本身也有缺陷，为了解决 分层带来的缺陷，利用x m l 技术和元数据技术实现了数据库字段同数据库表的松 耦合性，解决了分层引起的级联删除问题。把系统中的公用模块的功能以w i n d o w s 服务来实现，解决了分层带来的第二个缺陷：分层太多会影响到系统的性能。 模块之间的松耦合性也是影响系统松耦合性的一个重要因素，在设计过程中 使用设计模式可以降低模块之间的耦合程度，设计模式使用抽象耦合和分层技术 来提高系统的松散耦合度，从而从横向上实现了系统的松耦合性。典型的实现系 统松耦合的设计模式有：抽象工厂模式( a b s t r a c tf a c t o r y ) 、命令( c o m m a n d ) 模 式、观察( o b s e r v e r ) 模式和外观( f a c a d e ) 模式等。 本文首先分析了如何利用分层技术和o r m a p p i n g 技术来实现系统架构的松 耦合性，接着分析了解决分层技术的两个缺陷的方法。最后分析了如何通过运用 设计模式来实现模块之间的松耦合性。 通过以上的理论研究，本文结合一个具体的软件系统验证了理论研究的正确 性，介绍了该系统的整体框架，如何实现数据库结构的松耦合性和该系统中的 w i n d o w s 服务。并对其中的不足及应该改进的方面作了一定程度的分析。 1 3论文的组织结构 4 第一章：绪论。这部分讲述了软件系统开发的新需求，并且展示了本文的研究 背景。 第二章：松耦合性的理论概述。在这部分中，讲述了紧耦合系统与松耦合系统 的比较。突出松耦合性的优越性。 第三章：松耦合的架构。这部分分析了分层技术和0 r m a p p i n g 技术，详细介 绍了如何通过分层技术和0 r m a p p i n g 技术来实现系统的松耦合性。 第四章：松耦合的数据库结构和w i n d o w s 服务。这部分中首先讲述了如何通过 一些技术实现数据库字段同数据库表的松耦合，接着介绍了w i n d o w s 服务，通过 这两种方式避免了分层带来的缺陷。 第五章：为本系统的应用实例。在这部分介绍了一个具体系统的实现。同时验 证了研究理论的正确性。 第六章：总结与展望。分析了本系统的中比较成功的引入先进的应用集成技 术，并用于一个具体系统中的实际效果。同时也分析了其中的不足之处，提出了 一些将来可以改进的方向。 5 2 松耦合性与紧耦合性概述 2 1紧耦合系统概述 紧耦合系统通常提供直接的对象到对象通讯，对象间具有详细的了解。因为 紧耦合系统涉及直接的对象到对象通讯，所以对象通常比在松耦合系统中更为频 繁地交互，这样，如果两个对象位于不同的计算机上并且由网络连接分隔，则可 能导致性能和延迟问题。紧耦合意味着应用程序的不同组件之间的接口与其功能 和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的变更时， 它们就显得非常脆弱。 下图则显示了一个紧耦合的应用程序： 图1 紧耦合的应用程序 从上图中可以注意到一个问题，那就是大多数应用程序之间直接相互通信。 当应用程序需要修改或淘汰时，这种依赖便成为一个实际问题。任何修改都可能 会按其自身的方式更新每条唯一的通信线路。因此，这种变更可能代价高昂。对 于这种应用程序的维护和修改，逐渐成为让一些企业头疼的问题。 2 2松耦合系统概述 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵 6 活，以适应不断变化的环境，松耦合系统通常是基于消息或接口的系统，基于消 息的系统，客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的 通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可 以根据需要进行更改，而不必担心会破坏对方。基于接口的系统，系统划分为各 自独立的模块，但是各个模块必须提供标准的通用接口来同其它功能模块通信。 某个功能模块的内部实现对其它功能模块来说是透明的，当业务逻辑发生变化的 时候，只需要修改某一个功能模块，而不会影响到其它功能模块。 2 3松耦合系统的优越性 松耦合通讯机制提供了紧耦合机制所没有的许多优点： 系统的层次清晰，实现简洁 系统每个部分完成功能和目标是明确的，同样的功能，只在一个地方实现。 如果某个功能可以在系统不同的地方实现，那么，将会给后来的开发和维护带来 问题。系统简单明了，而系统架构过于复杂，会带来不必要的成本增加和维护难 度。在尽可能的情况下，一个部分完成一个单独并且完整的功能。 易于实现和有利于合作开发 对于一个松耦合系统的开发设计来说，功能模块划分的非常明确，开发人员 可以专注于开发自己负责的模块，而不必考虑其它模块的开发和设计。 可升级和可扩充性 一个系统框架，受设计时技术条件的限制，或设计者本人对系统认识的局限， 可能不会考虑到今后所有的变化。但是，系统必须为将来可能的变化做好准备， 在今后，能够在目前已有的基础上进行演进，而不会影响原有的应用。 松耦合对程序编写分工、程序的可维护性以及测试都有重要的关系，如：从 设计角度来看，在“强内聚、松耦合 的指导下进行设计得到的程序模块，符合 项目管理的工作分解结构( w b s ) 的要求，其相对独立的模块可以分配到具体的 程序员进行开发。另外，程序编码外包也必须建立在这种原则的设计之下。从程 序生命期角度来看，它有利于提高程序质量，特别是方便于程序的r 后维护，即 程序模块的相对独立性是可维护性的保证。从测试角度来看，符合“强内聚、松 耦合”的程序，易于对局部( 模块) 进行黑盒测试，也易于编写测试用例。 7 2 4系统的耦合程度 在软件领域，“耦合”一般指软件组件之间的依赖程度。软件耦合可以发生 在许多级别。在分布环境中，为了确定系统的耦合程度，必须分析各个级别。 在研究分布系统的“耦合 问题时，与远程组件的连接方式可能是最重要的 技术因素。在物理级别上，物理中介支持松耦合系统松散耦合，消息队列扮演中 介角色，解耦合消息的发送者和接收者。而形式的应用程序紧密耦合，因为客户 端和服务器直接交互，客户端要求服务器可用、可访问，以达到交互目的。 在“通信方式 级别上，同步和异步通信对耦合级别的影响经常与分布式组 件的物理链接密切相关。异步通信通常与松耦合相关。不过，这要求底层中间件 能以松耦合方式支持异步通信。以单向为例：虽然客户端不等待服务器的应答， 但单向仍然紧耦合，因为只有当客户端直接连接到服务器，而且服务器正在工作 和运行时，客户端才能发送单向请求。这是说明各种耦合度的极好例子：在适当 基础上建立的异步通信比异步单向调用的耦合程度更低。 研究分布式应用程序的类型系统级别的“耦合性”。可以看到，类型系统越 强，系统不同组件的依赖程度也越高。无论在应用程序开发阶段，还是在更改和 重新配置运行系统时，都是如此。接口提供了显式的接口名、操作名和强类型参 数。因此，组件在这个级别上达到紧耦合的程度，因为每次更改接口时，需要考 虑依赖的组件，影响会波及到整个应用程序。这样做的优点是：可以在编译时发 现受影响的应用程序部分，使其适应和反映更改，避免不兼容的消息格式引起运 行时异常。载荷语义的消息格式通常更灵活，故能降低组件的耦合级别。有些情 况下，可应用消息格式验证，但这要求参与者之间有效管理的最新模式定义。注 意，使用载荷语义并不能消除更改消息格式的问题。开发人员必须了解受更改影 响的系统部分，确保在采用新格式时，这些部分能正常运行。很多情况下，这往 往意味着问题从生成时转移到运行时。 分布式组件的“交互模式 对耦合度有何影响昵? 以基于o r b 的系统为例， 该系统通常采用面向对象的方式在复杂对象树中导航。客户端不仅需要了解各个 对象的逻辑，还必须了解如何在对象间导航，从而导致了高耦合性。形式接口不 支持这类复杂导航，但与分布对象系统相比，耦合程度降低了。基于的系统一般 采用更简单的交互模型，单个队列通常已足以作为客户端的输入点，服务器端事 务的所有输入在单个消息中提供。 另一个重要因素是处理逻辑的所有权或控制。如果集中管理过程，则不同子 过程和事务之间将紧密耦合。例如，数据库机制可用于确保不同子过程所拥有数 据的参考完整性和总体一致性。在大型单片式系统中，经常能看到这种情况。如 8 果业务流程高度分布则不同子过程和事务通常更独立，耦合程度更低。这时，必 须接受一个现实：不存在全局定义的统一过程状态。同样，不同参与者拥有的数 据可能不一致：一个系统已删除了一封订单，而另一个系统仍保存着清单。 最后，系统参与者互相定位的方式对系统的耦合级别有显著影响。静态绑定 的服务耦合性非常高，而动态绑定的服务则松散耦合。在命名和目录服务器中查 找服务可以降低服务之间的耦合程度，客户端只需要了解待绑定服务的准确名称 即可。命名服务等标准也支持服务发现。过去的经验证明，需要完全动态服务发 现的应用程序数量少而又少。 在制定架构决策时，必须认真分析耦合级别的优缺点。一般而言，在线事务 处理应用程序对松耦合的要求不高，这些应用程序在本质上是紧耦合的。若超出 一个企业或一个业务单元的范围，b 2 b 环境中，松耦合可能是惟一可选的解决方 案。大多数情况下，利用松耦合来增加灵活性会增加系统复杂度。为了运用更高 级松耦合系统概念，开发工作会更繁重，对开发人员的技术要求也更高，还必须 购买价格不菲的队列系统产品。但从长远看，如果经常调整耦合系统，松耦合投 资会引来丰厚回报。 9 3 松耦合的架构 3 1系统架构概述 从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则， 可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应保 持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去， 从而构成一个复杂的企业级架构。 当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的 架构及其应具有的功能行为以外，还要考虑整个架构的性能、容错能力、可用性、 可重用性、安全性、扩展性、可管理维护性和可靠性等各相关方面因素。一名好 的架构设计师还需要考虑所构建的系统架构是否合乎美学要求。由此可见，衡量 一个好的架构设计并不能只从功能角度出发，还要考虑很多其他方面的因素，对 任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。 3 2分层技术 在分解复杂的软件系统时，软件设计者用得最多的技术之一就是分层。在计 算机本身的架构中，到处都有分层的运用，不同的层从包含了操作系统调用的程 序设计语言，到设备驱动程序和c p u 指令集，再到芯片内部的各种逻辑门。网络 互联中，文件传输协议( f 】m ) 层架构在传输控制协议( t c p ) 层之上，t c p 层架 构在( i p ) 层之上，i p 层又架构在以太网之上。 当用分层的观点来考虑系统时，可以将各个子系统想像成按照层次的形式来 组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的 各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的实 现细节。将系统按照层次分解有很多重要的好处t 1 在无需过多了解其它层次的基础上，可以将某一层作为一个有机整体来理 解，例如，无需知道以太网的工作细节，照样可以在t c p 上构建f t p 服务。 2 可以替换某层的具体实现。只要前后提供的服务相同即可。例如，f t p 服 务无论是在以太网，还是网络运营商使用的任何网络上都无需改变、而且与提供 传输电缆的网络运营商无关。 3 可以将层次间的依赖性减到最低。假设网络运营商改变了物理传输系统， 1 0 但只要口层不变，f t p 层服务就可以不改变。 4 分层有利于标准化工作。t c p 和m 就是关于它们各自层次如何工作的标 准。 5 一旦构建好了某一层次，就可以用它为很多上层服务提供支持。因此， t c p i p 同时被f t p ，t e l n e t ，h t r p 使用。否则，所有这些高层协议都必须编写 它们各自的底层协议。 分层是一种重要的技术，但是也有缺陷： 1 层次并不能封装所有东西。有时会带来级联修改，最典型的例子是在一个 分层设计的企业应用中，如果要增加一个在用户界面上显示的数据域，就必须在 数据库中增加相应的字段，还必须在用户界面和数据库之间的每一层做相应的修 改。 2 过多的层次会影响性能。在每一层，一般都会从一种表现形式转到另一种。 不过底层功能的封装通常带来比代价更大的效率提升。例如，可以优化事务控制 层，提高其它各层的效率。 3 3软件系统体系结构 3 3 1 二层应用程序构架 2 0 世纪9 0 年代，随着客户服务器系统的出现，分层的概念更清晰了。这样 的系统是一种两个层次的系统：客户端包括用户界面和其它应用代码，服务器端 通常是关系型数据库。在这种解决方案中，客户端程序负责数据访问、实现业务 逻辑、用合适的样式显示结果、弹出预设的用户界面、接受用户输入等。这使得 重用业务逻辑和界面逻辑非常困难。 如果应用仅仅包括关系数据的简单显示和修改，那么这种客户服务器系统的 工作方式非常适合。问题来自业务逻辑，如业务规则、验证、计算等。通常，人 们会把它们写在客户端，但是这样很笨拙，并且往往把业务逻辑直接嵌入到用户 界面。随着业务逻辑的不断复杂化，这些代码将越来越难以使用，而且易产生冗 余代码，这意味着简单的变化都会导致要在很多界面中寻找相似代码。另外一种 办法是把这些业务逻辑放到数据库端，作为存储过程。但是，存储过程只提供有 限的结构化机制，这将再次导致笨拙的代码。 3 3 2 三层应用程序构架 在客户服务器逐渐大众化的同时，面向对象方式开始崛起，面向对象为业务 逻辑的问题找到了答案：转到三层架构的系统。在这种方式下，在表现层实现用 户界面，在业务层实现业务逻辑，在数据源层存取数据。这种方式使得我们可以 将复杂的业务逻辑从界面代码中抽取出来，单独放到中间层，用对象加以建模和 组织。 三个基本层次：表现层，业务层，数据源层。如下图： 鼠次 职啬 度现屏 提供服务显示信息例如存w i n d o w s 戎l r 哺亿页面巾，处瑰 用户漪求( 鼠标点击缝盘敲击铎 。f f l 。 p 请求命令行调用， 批处- 哩a p i ) 领域层 逻辑系统中真正的核心 数据矗暖层 与数据库消息系统事务管理器及其他钦仲包通估 _ _ 一_ 一_ 一i - _ _ - _ - _ _ _ _ _ _ - _ - - _ - _ _ _ - _ _ _ _ _ - _ - _ _ _ _ _ _ 一 图2 三层描述 表现逻辑处理用户与软件间的交互。可能简单到只是命令行或基于文本的菜 单系统，但是当前的客户界面往往是功能完善的胖客户界面，或者是基于h t m l 的 浏览器界面。表现层的主要职责是向用户显示信息并把从用户那里获取的信息解 释成业务层或数据源层上的各种动作。 数据源逻辑主要关注与其它系统的交互，这些系统将代表应用完成相关的任 务。它们可以是事物监控器、消息系统或其他应用等。对于大多数企业应用来说， 最主要的数据源逻辑就是数据库，它的主要责任是存储持久数据。 业务逻辑是应用必须做的所有业务相关工作：包括根据输入数据或已有数据 进行计算。对从表现层输入的数据进行校验，以及根据从表现层接收的命令来确 定应该调度哪些数据源逻辑。 3 3 3 多层应用程序构架 多层架构的核心思想是，将整个业务应用划分为表示层一业务层一数据访问 层一数据库等等更多的层次，明确地将客户端的表示层、业务逻辑访问、数据访 问及数据库访问划分出来，十分有利于系统的开发、维护、部署和扩展。使用多 层架构进行系统开发是当前系统设计的流行趋势。通过分解业务细节，将不同的 功能代码分散开来，更利于系统的设计和开发，同时为可能的变更提供了更小的 单元。 多层架构一般是把业务逻辑层再进一步的细分为两层，下面以两种多层架构： 表现层一业务逻辑层一数据库访问层一数据库层和表现层一服务层一业务逻辑层 1 2 一数据库层为例来介绍多层架构。 第一种多层架构是把数据访问的逻辑从业务逻辑层中分离出来，作为单独的 一层存在。在后续的文章中介绍了如何使用0 r m a p p i n g 技术来实现数据逻辑层同 业务逻辑层的分离。进一步提高系统的松耦合性。 第二种多层架构是把业务逻辑处理层分成了两层，服务层和业务逻辑处理层。 服务层放置在业务逻辑处理层之上，主要是封装业务逻辑处理层。对表现层提供 接口。表现层与业务逻辑处理层的交互完全通过服务层，就像应用程序的a p i 一 样。 在提供一个清晰的a p i 的同时，服务层也可以放置事物控制和安全等功能。 这样做可以获得一个简单的、饱含了服务层所有方法并描述了事物和安全特征的 模型。通常，通过一个独立的特性文件来描述这一模型，n e t 中的属性值提供了 一个直接在代码中进行描述的好方法。 如果设立了服务层，在其中置入行为的多少是一个至关重要的决定。最小化 情况下，服务层只是一个外观，所有实际的行为都在下层的对象中，服务层所做 的只是将上层调用传递到更低层。在这种情况下，服务层提供一个更易于使用的 a p i ，因为它的方法通常根据用例来组织。此时，它也提供一个很方便的切入点， 用来增加事物封装和安全检查等功能。 3 4系统分层所遵从的原则 系统分层必须遵循的最重要的原则就是松耦合。软件分层的本来目的，就是 提高软件的可维护性和可重用性，而高内聚和松耦合正是达成这一目标必须遵循 的原则。尽量降低系统各个部分之间的耦合度，是分层设计中需要重点考虑的问 题。内聚和耦合，包含了横向和纵向的关系。功能高内聚和数据低耦合，是我们 需要达成的目标。横向的内聚和耦合，通常体现在系统的各个模块、类之间的关 系，而纵向的耦合，体现在系统的各个层次之间的关系。系统的框架，通常包含 了一系列规范、约定和支撑类库、服务。对于如何判断一个软件的系统框架是否 符合系统的松耦合性的标准，应该遵循的原则如下： 1 系统的内聚和耦合度，这是保证一个系统的架构是否符合软件工程原则的 首要标准。 2 层次的清晰和简洁性，系统每个部分完成功能和目标必须是明确的，同样 的功能，应该只在一个地方实现。如果某个功能可以在系统不同的地方实现，那 么，将会给后续的开发和维护带来问题。系统应该简单明了，过于复杂的系统架 构，会带来不必要的成本增加和维护难度。在尽可能的情况下，一个部分应该完 成一个单独并且完整的功能。 3 易于实现性，如果系统架构的实现非常困难，甚至超出团队现有的技术能 力，那么，团队不得不花费更多的精力用于架构的开发，这对于整个项目来说， 可能会得不偿失。 4 可升级和可扩充性，一个系统框架，受设计时技术条件的限制，或者设计 者本人对系统认识的局限，可能不会考虑到今后所有的变化。但是，系统必须为 将来可能的变化做好准备，使其今后能够在目前已有的基础上进行演进，而不会 影响原有的应用。接口技术，是在这个方面普遍应用的技巧。 5 是否有利于团队合作开发，一个好的系统架构，不仅仅只是从技术的角度 来看，而且，它还应该适用于团队开发模型，可以方便一个丌发团队中各个不同 角色的互相协作。例如，将w e b 页面和业务逻辑组件分开，可是使页面设计人员 和程序员的工作分开来同步进行而不会互相影响。 6 性能，性能对于软件系统来说是很重要的，但有时为了能让系统得到更大 的灵活性，可能不得不在性能和其他方面取得平衡。另外一个方面，由于硬件技 术的飞速发展和价格的下降，性能的问题往往可以通过使用更好的硬件来获得提 升。 7 依赖性的普遍原则，业务层和数据源层绝对不要依赖于表现层。即在业务 层和数据源层的代码中，不要出现调用表现层代码的情况。这条规则将简化在相 同的基础上替换表现层的代价。也使得表现层的修改所带来的连锁反应尽可能小。 业务层与数据源层的关系更复杂，其取决于数据源层的架构模式。 3 5 分层技术与o r m a p p i n g 技术 在简单应用中，业务模型是一种和数据库结构相当一致的简单结构，对应每 个数据库表都有一个业务类。这种业务对象的业务逻辑复杂度通常适中。在这种 情况下，每个业务对象负责数据库的存取过程，这也就是活动记录。从另一个角 度来考虑活动记录，就是从行数据入口开始，然后把业务逻辑加入到类中。 如下图所示： 图3 业务对象与数据库表对应图 1 4 随着业务逻辑变得更加复杂，它就慢慢转变成一个大的业务模型，简单的活 动记录开始不能满足要求了。业务类和表的一对一匹配也开始随着把业务逻辑放 人更小的类而失效。关系数据库无法处理继承，因此使用策略模式和其他轻巧的 面向对象模式非常困难。随着业务逻辑日益活跃，我们希望不用访问数据库就能 随时测试它。 所有这些都迫使你随着业务模型的增大而采用间接的方式。在这种情况下， 入口可以解决一些问题但它仍然将数据库方案和业务模型耦合在一起。结果就 会有一些从入口域到业务对象域的转换，这种转换会使业务对象变得复杂。 一种更好的办法是把业务模型和数据库完全独立，可以让间接层完成业务对 象和数据库表之间的映射。这个数据映射器处理数据库和业务模型之间所有的存 取操作，并且允许双方都能独立变化。这是数据库映射架构中最复杂的架构，但 它的好处是把两个层完全独立了。 图4 数据映射器模式 分层技术是把系统结构分成了三个基本的层次，当业务逻辑层比较复杂的时 候，我们会进一步的细分，基于这种情况，我们会引入一些技术来把业务逻辑层 进一步的划分为不同的层次。使得系统更加的松散耦合。o r m a p p i n g 技术正是解 决这种问题的一种非常好的技术之一。 3 6 o - r m a p p i n g 技术 3 6 1o r m a p p i n g 技术简介 对象关系映射( o b j e c tr e l a t i o n a lm a p p i n g ，简称o - r m a p p i n g ) 是一种为了解 决面向对象与关系数据库存在的互不匹配现象的技术。简单的说，o r m a p p i n g 是 通过使用描述语言来描述数据库与对象之间的映射关系，并将程序中的对象自动 持久化到关系数据库中，本质上就是将数据从一种形式转换到另外一种形式。 o r m a p p i n g 说到底就是帮我们生成了一个功能强大的数据库访问类，将数据库中 的实体( 一般是一张表) 映射为类，对数据库的操作就直接转换为对这些实体的操 作：包括增、删、改等。采用实体的操作，会使我们对数据库访问时，更方便， 减少很多不必要的代码，在数据库操作中，用得最多的是数据获取( r e t r i e v e ) 。查 询条件也是很多样，会有关联查询的情况，获取的结果也是要定制的，而不是简 单的每个表的所有字段。实际上，o r m a p p i n g 就是在应用程序中的对象和数据库 的业务实体之间建立了一座桥梁，起到一个适配器的作用。他的设计思想类似于 设计模式中的a d a p t e r 模式。 3 6 2i ji , ho r m a p p i n g 的原因 在目前的企业应用系统设计中，m v c ，即模型( m o d e l ) 一视图( v i e w ) 一控 制( c o n t r 0 1 ) 为主要的系统架构模式。m v c 中的m o d e l 包含了复杂的业务逻辑 和数据逻辑，以及数据存取机制。将这些复杂的业务逻辑和数据逻辑分离，以将 系统的紧耦合关系转化为松耦合关系( 解耦合) ，是降低系统耦合度迫切要做的， 也是持久化要做的工作。m v c 模式实现了架构上将表现层( v i e w ) 和数据处理 层( m o d e l ) 分离的解耦合，而持久化的设计则实现了数据处理层内部的业务