（计算机应用技术专业论文）一个轻量级企业应用框架的设计实现及应用.pdf

摘要 框架，即f r a m e w o r k ，目前还没有统一的定义。其中r a l p hj o h n s o n 所给出的 定义基本上为大多数研究人员所接受：框架是整个或部分应用系统的可重用设计， 它表现为一组抽象组件及组件之间的交互。一个框架是一个可复用的设计构件， 它规定了应用的体系结构，阐明了整个设计、构件之间的依赖关系、责任分配和 控制流程，为构件复用提供了上下文( c o n t e x 0 。框架提供了所有应用期望的默认行 为的类集合，具体的应用通过重写子类( 该子类属于框架的默认行为) 或组装对象来 支持应用专用的行为。应用框架并不是构建应用程序的小片程序，而是实现了某 应用领域通用完备功能( 除去特殊应用的部分) 的底层服务。应用框架强调的是 软件的设计重用性和系统的可扩充性，以缩短大型应用软件系统的开发周期，提 高开发质量。与传统的基于类库的面向对象重用技术比较，应用框架更注重于面 向专业领域的软件重用，构件根据框架进行复合而生成可运行的系统。 由于通常会处理大量关系复杂的数据，并且这些数据来自于多个不同的数据 源，分布式应用系统的开发一直是复杂和困难的。在多层分布式应用中，客户端 和服务器之间可以加入一层或多层应用服务程序，这种程序称为“应用服务器” ( a p p l i c a t i o ns e r v e r ) 。开发人员可以将企业应用的商业逻辑放在中间层服务器上， 而不是客户端，从而将应用的业务逻辑与用户界面隔离开，在保证客户端功能的 前提下，为用户提供一个瘦的m i i n ) 界面。这意味着如果改变了业务规则，则可以 只在一处( 中间层服务器上) 修改，而不用修改成千上万的客户端应用程序。从而使 开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了企业系 统的开发、更新和升级工作，极大地增强了企业应用的伸缩性和灵活性。 l e a f 框架以面向对象思想为基础，是一个针对分布式体系结构的轻量级企 业应用框架，它充分利用n e t2 0 框架的范型、r e m o t i n g 、反射和特性等技术，为 分布式应用系统开发人员解决了诸如多级级联对象的状态更新及撤销、数据校验 和系统安全、统一的数据访问方式等一系列问题，在l e a f 框架的基础之上，开 发人员可以方便地创建业务组件，搭建分布式应用系统。 关键词：轻量级，企业应用，框架，分布式 a b s t r a c t b yn o w , t h c r ei sn oc o n s e n s u sd e f i n i t i o no nf r a m e w o r k i ti sam o s ta c c e p t a b l e d e f i n i t i o nf o rl o t so fs t u d i e st h a tf i - a m e w o r ki sar e u s a b l ed 髂i g no fw h o l eo rp a r t i a l a p p l i c a t i o ns y s t e m , w h i c hi sp r e s e n t e db yr a l p hj o h n s o n f r a m e w o r k , w h i c hd e c i d e a p p l i c a t i o na r c h i t e c t u r e ，c h a d f yt h ed e p e n d e n c yb e t w e e nc o l l a b o r a t ec o m p o n e n t , a s s i g n r e s p o n s i b i l i t y , c o n t r o lp r o c e s sa n dp r o v i d ec o n t e x tf o rr e u s i n gc o m p o n e n t , i sar e u s a b l e d e s i g nc o m p o n e n t c l a s s e sa s s e m b l yo fd e f a u l tb e h a v i o u re x p e c t e db ya p p l i c a t i o n si s c o n t a i n e di nf i a m e w o r k c o n c r e t ea p p l i c a t i o n 锄h a v es p e c i a lb e h a v i o u ro fi 协c l fb y r e w r i t i n gc h i l dc l a s so rc o m p o s i n gc l a s s e s c o m p a r e dw i t ht r a d i t i o n a lo b j e c to r i e n t e d r e u s et e c h n i q u eb a s e do nc l a s s e sl i b r a r y , a p p p l i c a t i o nf r a m e w o r ki st e n dm o r et or e u s e s o f t w a r ei np r o f e s s i o n a la r e a t od e v e l o pd i s t n b u t e da p p l i c a t i o ni sv e r yc o m p l i c a t e da n dd i f f i c u l tb e c a u s ei t u s u a l l yi n v o l v el a r g ev o l u m ed a t aw h i c hm a yc o m ef r o mm a n yd a t as o u r c e s i n m u l t i - l a y e r d i s t r i b u t e d a p p f i c a f i o n s , o n e d rm u l t i l a y e r sa p p l i c a t i o n s e r v i c e p r o g r a m ，w h i c hi sr e f c r e dt oa sa p p f i c a t i o ns e r v e r , c a nb el o c a t e db e t w e e nc l i e n ta n d s e r v e r d e v e l o p e r sd 0n o tp u tb u s i n e s sl o g i ci nc l i e n t b u ti na p p l i c a t i o ns e r v e r t h u s i s l o a t eb u s i n e s sl o g i cw i t ha p p l i c a t i o nu ii n t e r f a c ea n dp r o v i d ec l i e n tat h i n n e r i n g e r f a e e t h i sa l s om e a n sd e v l e o p e r so n l yc h a n g ec o d ei na p p l i c a t i o ns e r v e rw h e n b u s i n e s sm g i cc h a n g e d , n o tl o t so fc l i e n ta p p l i c a t i o n s a sar e s u l t ，d e v e l o p e r sn e e do n l y f o c u s0 1 1 d e s i g n i n g ，a n a l y s i z a t i o n a n d d e v e l o p i n g o fc o r eb u s i n e s s l o g i c i n a p p l i a t i o n t h i ss m i p l i f i e d t h ed e v e l o p i n g , u d p a t i n ga n du p g r a d i n go fe n t e r p r i s e a p p l i c a t i o na n dd r a m a t i c a l yi n h e u s e di t ss c a l a b i l i t ya n df l e x i b i l i t y b a s e do no b j e c to r i e n t e dp r o g r a m m i n gs t y l e ，le a fi sal i g h t w e i g h tf r a m e w o r kt o h e l pa p p l i c a t i o nd e v e l o p e r s c r c a t ed i s t r i b u t e d a p p l i c a t i o n s l e a f f r a m e w o r k s u f f i c i e n t l y 嗽r e f l e c t i o n , g e n e r i c s , r e m o t i n ga n da t t r i b u t e sa n dp r o v i d ed i s t r i b u t e d a p p l i c a t i o np o w e r f u ls u p p o r t ss u c ha sn - l e v e lu n d o p n p ( p h i ga n dp l a y ) v a l i d a t e da n d a u t h o r i z e dm l e s ，d a t aa c c e s sg a t e w a y , a n ds oo n b a s e do nl e a f , d e v e l o p e r sc a ne a s i l y c r e a l cb u s i n e s so b j e c ta n dd i s t r i b u t e ds y s t e m k e y w o r d s ：l i g h t w e i g h t ，e n t e r p r i s ea p p l i c a t i o n , f r a m e w o r k , d i s t r i b u t e d 修改提纲 1 、英文摘要设置为两端对齐： 2 、修改目录内容和页码； 3 、第一页第1 6 行 原文为： 但即使没有那么多用户这个经常发生的问题不会发生。 修改： 删除 4 、第1 页，第1 9 行加入： 企业应用通常需要与多个其它应用系统交互。 5 、第8 页 图2 - 1 内容更改为中文 6 、第1 l 页( 原文第1 3 页) 图3 - 2 内容修改为中文 7 、第1 8 页第2 7 行( 原文第2 0 页第1 1 行) 原文为： d a t a p o r t a l 类似于路由的概念业务对象可以很容易成为可移动对象。 改为： 分布式应用系统大都采用三层体系结构并负责维护客户与应用服务器上的业务对象 之间的通信。 8 、第1 8 页，第1 2 行 新增图4 - 2d a t a p o r t a l 结构 9 、第1 9 页第2 5 行( 原文第2 1 页，第2 1 行) 原文为： 在n e t 框架中，这样业务对象方法的调用不会引起网络通信代价。 改为： 可移动业务组件回答了分层结构带来的第二个问题，我们利用n e t2 0 平台下的范 型技术将业务组件实现为强类型。 l o 、第2 2 页( 原文2 4 页) 删除数据绑定节 1 1 、第2 2 页第5 行( 原文第2 6 页1 0 行) 增加图4 - 6c o p y s t a t e 方法流程 1 2 、第2 6 页第8 行( 原文篼3 0 页5 行) 原文代码删除 13 、第3 1 页第13 行( 原文第40 页第8 行) 图4 - 8g e t m e t h o d 方法流程图内容改为中文 14 、第33 页第2 1 行( 原文第4 2 页23 行) 删除4 6 2 1b a t a p o z t a l 事件节 15 、第3 4 页第13 行( 原文第4 4 页第6 行) 增加图4 - 9 通道适配器实现 16 、第3 5 页第2 行( 原文第4 6 页第1 行) 原文为： 图4 - 9f e t c h 方法处理过程 修改为： 图4 - 1 0 ( 内容改为中文) 17 、第3 9 页第12 行( 原文第5 2 页第2 3 行) 增加图4 - 13d a t a p o r t a l 消息路由器实现流程 l8 、第43 页第1 行( 原文第5 8 页第1 行) 原文为： l e a f 框架在n - t i e r 财务管理系统中的应用 修改为： l e a f 框架在n - t i e r 订单管理系统中的应用 19 、第46 页第8 行( 原文第6 l 页4 行) 删除5 2 3 数据库设计节 2 0 、第4 7 页第2 l 行( 原文第6 5 页第1 8 行) 删除5 3 2c u s t o m e r 业务组件节 2 1 、第5 2 页第1 5 行( 原文第7 9 页) 增加图5 - 4o r d e r s h i p p i n g 子对象数据访问u m l 序列图 2 2 、第5 6 页第1 行( 原文第8 6 页1 1 行) 增加图5 - 6 用户登录过程 指导老师 答辩主席 日期： 、 多彰 v， 多传 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的说明并表示谢意。 签名：缝鱼：日期：哆年z 月严日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名：墨垒= 奎导师签名：歪鏖! 三 目期：9 夕年f 月尸日 第一章绪论 第一章绪论 在m a r t i nf o w l e r 的名著( p a t t e r n so fe n t e r p r i s ea p p l i c a t i o na r c h i t e c t u r e ) ) 中， 企业应用具有以下一些特点： 企业级应用通常涉及到数据的持久保存。由于数据在程序运行中到处都要 用到，因此必须持久保存而且通常要保存很多年。在这段时间里，使用数据的程 序也会经常的发生改变。常见的情况是，数据的寿命比创造他们的硬件系统、操 作系统、编译器还要长。这段时间里，在不影响原有信息的前提下，为了存储新 的信息，数据的结构也会因此发生很多变化。 企业级应用包含的数据量很大，一个中型的系统就会包含超过1 g b 的数据 量，它们被组织成上千万条记录。管理这些数据就成为这个系统的主要部分。较 早的系统使用索引文件结构像m 的v s a m & i s a m 。现代的系统经常使用数据 库，大多数是关系型数据库。数据库的设计和数据的填充已经变成了其自身的一 个分支专业了。 通常很多人并发地存取数据。对很多系统来说，使用人员可能不到百人， 但是对i n t e m e t 上基于w e b 的系统来说，使用者的递增速率就是几何级的。这么多 的使用者，确保他们都能从系统中正常地访问数据就是一个非常重要的问题。用 户数量过多带来的沉重压力，通过事务管理工具来处理仅仅只能解决一部分，而 通常应用开发人员也根本不可能完全解决这个问题。 企业应用通常需要与多个其它应用系统交互。通常来说，企业应用系统会 经常性地与其它应用系统进行数据和业务的交互。因此，企业应用系统集成e a i ( e n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ) 成为当前企业应用开发中的一个热点话题。 j 2 e e 是当前企业应用市场中当之无愧的霸主，得益于j a v a 语言的开放性，出 现了相当多的针对某一领域的j a v a 应用框架。由于大多数框架都是开源的，使得 这些框架获得了持久的发展和完善。比如在w e b 开发领域，就有s t r u t s 、w e b w o r k 等，在o r m 领域有事实上的标准h i b e r n a t e ，有了这些开源框架的支持，开发人 员就无需事无巨细地搭建应用系统了。r o dj o h s o n 于2 0 0 3 年开发了s p r i n g 框架， 它是一个轻量级的企业应用框架，也是j a v a 开源社区中广受推崇的一个应用框架。 1 电子科技大学硕士学位论文 团曰 圈圈 图卜1s p r i n g 框架结构图 其中，c o r e 是s p r i n g 框架的核心部分，它是一个i o c 容器，实现了依赖注入 特性，将依赖关系从程序逻辑中真正分离出来了。通过x m l 配置文件，可以指定 对象依赖关系，而由i o c 框架来完成对象创建。 从图1 - 1 中还可以看到s p r i n g 框架内建了针对w e b 应用的m v c 子框架，o r m 层封装了h i b e r n a t e 、j p a 、j d o 和i b a t i s 编程接口，a o p 子框架提供了面向方面 编程的实现。 当然，这种趋势也不仅是出现在j a v a 领域，愈来愈多的开源框架也出现在 了n e t 应用中。它们大多仿效j a v a 中的开源框架，如n h i b e m a t e 、c a s t l e 等，为n e t 企业应用提供了一定的支撑。 由于通常会处理大量关系复杂的数据，并且这些数据可能会来自于多个可能 的数据源，分布式应用系统的开发一直是复杂和困难的。在传统的c l i e n t s e r v e r 结构中，应用程序逻辑通常分布在客户和服务器两端，客户端发出数据资源访问 请求，服务器端将结果返回客户端。c l i e n t s e r v e r 结构的缺陷是，当客户端数目激 增时，服务器的性能将会因为无法进行负载平衡而大大下降。而一旦应用的需求 发生变化，客户端和服务器端的应用程序则都需要修改，这样给应用的维护和升 级带来了极大的不便，而且大量数据的传输也增加了网络的负载。为了解决 c l i e n t s e r v e r 结构存在的问题，只有向多层分布式应用转变。 在多层分布式应用中，客户端和服务器之间可以加入一层或多层应用服务程 序，这种程序称为“应用服务器”( a p p l i c a t i o ns e r v e r ) 。开发人员可以将企业应用 2 第一章绪论 的商业逻辑放在中间层服务器上，而不是客户端，从而将应用的业务逻辑与用户 界面隔离开，在保证客户端功能的前提下，为用户提供一个瘦的m 曲) 界面。这意 味着如果需要修改应用程序代码，则可以只在一处( 中间层服务器上) 修改，而不用 修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务 逻辑的分析、设计和开发，简化了企业系统的开发、更新和升级工作，极大增强 了企业应用的伸缩性和灵活性。 尽管多层分布式体系结构为企业提供了极大优势，但比起传统的c l i e n t s e r v e r 方式，开发多层分布式应用具有更大的难度，给开发人员带来了新的技术挑战。 主要包括了以下三个方面： 1 、分布式对象标准的多样化 企业要构建多层分布式系统，必须遵循分布式的工业标准，基于什么样的标 准直接影响到企业应用系统的开放性和可扩展性。目前分布式对象的标准主要有 三种：m i c r o s o f t 的d c o m 、s u nm i c r o s y s t c m s 的e n t e r p r i s ej a v a b e a n s r m i 以及 o m g ( o b j e am a n a g e m e n tc r o u p ) 组织的c o r b a ( c o m m o no b j e c tr e q u e s tb r o k e r a r c h i t e c t u r e ) 。d c o m 是基于w i n d o w s 环境的分布式对象标准，因此支持的平台种类 有限。砌m 与e n t e r p r i s ej a v a b e a n 是以j a v a 语言为主体的分布式对象架构，适合 大型企业的跨平台需求，但现实的应用系统环境一般是由多种不同的程序语言建 立起来的，只依赖一种程序语言构建的企业应用是很少见的。c o r b a 是由8 0 0 多 个大型软、硬件公司参与的o m g 组织所制定的分布式对象标准，获得m m 、s u n m i c r o s y s t e m s 、o r a c l e 、s y b a s e 、n o v e h 、n e t s c a p e 等大型公司的支持，c o r b a 标 准实现了不同平台之间对象的通信及互操作，软件供应商只要遵循应用对象与 o r b 问通信的i d l ( i n t e r f a c ed e f i n i t i o n a n g u a g e ) ，便能够以对象的形式提供服务 或获得服务。o r b 使开发人员完全不需要考虑异构平台、不同的通信协议或不同 程序语言造成的差异，而专注于应用逻辑的开发。可见，c o r b a 提供了开放、灵 活的分布式标准，适于企业构建多层分布式应用系统。 2 、多层分布式应用的开发是很复杂的 如果用传统方式开发多层分布式应用，则需要开发人员具有较深的计算机系 统级知识，需要掌握诸如并发性、安全性、可伸缩性及事务处理等各个方面的知 识。而且需要实现对系统资源访问的有效管理，如对线程、内存、数据库连接、 网络连接的管理。而这些复杂工作极大地耗费了开发人员的精力，限制了开发工 3 电子科技大学硕士学位论文 作的进展。而企业应用系统的开发更多地要求开发人员专注于商业逻辑方面的开 发，而不是在系统级开发上浪费更多时间。 在传统的两层应用系统中，通过两阶段提交可以确保事务的a c i d ( a t o m i c i t y 、 c o n s i s t e n c y 、i s o l a t i o n 、d u r a b i l i t y ) 属性。但在分布式应用系统中，要确保涉及多 个数据库的数据操作的事务性是最为突出的一个问题。 设想有一个事务，要求数据变化发生在两个分离的数据库中，仍然要求所有 的a c i d 特性测试能够满足。基本的事务处理不能满足要求，因为如果其中一个 数据库服务器失败，无法确保另外一个数据库的数据还没有提交并成为永久的。 换句话说，无法协调发生在不同地方的多个事务处理就没有办法保证事务的原子 性。 3 、分布式应用的分发、管理也是一个挑战 大多数的分布式应用是由成百上千的组件组成的，而在分发时，每一个组件 都有属性需要进行配置。通常，对组件属性的配置方式依赖于组件所在的平台。因 此，应用被分发后，如何管理分散的组件将是一个挑战。管理者需要确保应用的 组件能够正确运行、可以位于企业网内的任何机器上，并能及时发现处理错误( 包 括系统错误、网络中断、应用错误等情况) 。对于分布式应用系统来说，一个应用 并非运行于某一台主机，因此，管理者需要管理整个网络的状态，这就需要有恰 当工具的支持。 本文以n e t 2 0 框架为基础，设计实现了一个针对分布式体系结构的轻量级企 业应用框架l e a f 。l e a f 框架以o o ( o b j e c to r i e n t i e d ) 思想为基础，充分利用 了n e t2 0 的范型、r e m o t i n g 、反射和特性等技术，为分布式应用系统开发人员解 决了一系列问题。 我们将l e a f 框架分为c o r e 、d a t a p o r t a l 、v a l i d a t i o n 和s e c u r i t y 四个主要部分 来逐步实现。c o r e 是l e a f 框架的核心部分，所用应用系统的业务组件都间接从 b u s i n e s s b a s e 继承而来。通过d a t a p o t t a l ，u i 层可以调用应用服务器上的业务组件 方法。它实现了通道适配器和消息路由器模式，使u i 层无需关心底层网络通信协 议。v a l i d a t i o n 部分提供了即插即用型的数据验证组件，业务组件的属性通过 v a l i d a t i o n 来进行各种自定义数据验证。s e c u r i t y 是安全层，为业务组件的提供授 权和用户验证功能。 4 第二章框架理论 第二章框架理论 框架的概念最早起源于s m a l l t a l k 环境，其中最著名的框架是s m a l l t a l k8 0 的用 户界面框架m v c ( m o d c l v i e w - c o n t r o l l e r ) 。随着用户界面框架i n t e r v i e w s 和e r + + 的开发和发布，框架技术越来越受到研究人员的重视。虽然框架研究最初起源于 用户界面领域，但它还被成功地应用到其他领域中，如操作系统、火警系统等。 框架目前还没有统一的定义，其中r a l p hj o h n s o n 所给出的定义基本上为大多 数研究人员所接受：框架是一个可复用设计，它是由一组抽象类及其协作关系来 表达的。这个定义是从框架内涵的角度来定义框架的。b o s c h 从框架用途的角度来 给出了框架的另一个定义：框架是在一个给定的问题领域内，一个应用程序的一 部分设计与实现。 从以上两个定义可以看出，框架是对特定应用领域中的应用系统的部分设计 和实现，它定义了一类应用系统( 或子系统) 的整体结构。框架将应用系统划分为类 和对象，定义类和对象的责任，类和对象如何互相协作，以及对象之间的控制流 程。这些共有的设计因素由框架预先定义，应用开发人员只须关注于特定的应用 系统特有部分。框架刻画了其应用领域所共有的设计决策，所以说框架着重于设 计复用，尽管框架中可能包含用某种程序设计语言实现的具体类。 设计复用导致了应用系统和框架之间的反向控制i o c ，由于基于同一框架的 应用系统都具有相似的结构，这也带来了更简单的维护代价和一致的用户体验。 一个基于框架开发的应用系统包含一个或多个框架，与框架相关的构件类，以及 与应用系统相关的功能扩展。与应用系统相关的扩展包括与应用系统相关的类和 对象。应用系统可能仅仅复用了面向对象框架的一部分，或者说，它可能需要对 框架进行一些适应性修改，以满足系统需求。 面向对象的框架作为一种可复用的软件，在基于框架的软件开发过程中会涉 及到框架的开发和利用两个方面的工作。框架的开发阶段在于产生领域中可复用 的设计。该阶段的主要结果是框架以及与框架相关的构件类。该阶段的一个重要 活动是框架的演变和维护。象所有软件一样，框架也易于变化。产生变化的原因 很多，如应用出错，业务领域变化等等。 5 电子科技大学硕士学位论文 2 1 白盒与黑盒框架 基于继承的框架被称为白盒框架。所谓白盒即具备可视性，被继承的父类的 内部实现细节对子类而言都是可知的。利用自盒框架的应用开发者通过衍生子类 或重写父类的成员方法来开发系统。子类的实现很大程度上依赖于父类的实现， 这种依赖性限制了重用的灵活性和完全性。但解决这种局限性的方法可以是只继 承抽象父类，因为抽象类基本上不提供具体的实现。白盒框架是一个程序骨架， 而用户衍生出的子类是这个骨架上的附属品。 基于对象构件组装的框架就是黑盒框架。应用开发者通过整理、组装对象来 获得系统的实现。用户只须了解构件的外部接口，无须了解内部的具体实现。另 外，组装比继承更为灵活，它能动态地改变，继承只是一个静态编译时的概念。 在理想情况下，任何所需的功能都可通过组装已有的构件得到，事实上可获 得的构件远远不能满足需求，有时通过继承获得新的构件比利用已有构件组装新 构件更容易，因此白盒和黑盒将同时应用于系统的开发中。不过白盒框架趋向于 向黑盒框架发展，黑盒框架也是系统开发希望达到的理想目标。 2 2 热点、食谱以及好莱坞原则 成功的框架开发需要确定领域专用的“热点”( i | o ts p o t ) 。应用开发者在框架 的基础上进行开发，只须扩展框架的某些部分，“热点”就是在应用领域的一种扩 展槽，开发者根据自己的需要填充这些扩展槽。“热点”使框架具有灵活性，如在 具体的实现中，扩展槽可以被看成是一些抽象类，开发者通过重写抽象方法获得 具体实现。 “食谱”( c o o k b o o k ) 就是描述如何使用框架方法的文档。在“食谱”中包含 了许多“烹饪”方法，这些“烹饪”方法相当于一些具体的操作步骤，描述了为 解决某一专门问题如何使用框架的详细方法。框架的内部设计和实现细节通常不 出现在“食谱”中。 框架的一个重要特征就是用户定义的方法经常被框架自身调用，而不是从用 户的应用代码中调用。这种机制常称为“好莱坞原则”( h o l l y w o o de m c i p l e ) 或“别 调用我们，我们会调用您”。 6 第二章框架理论 2 3 反向控制i o c 从“好莱坞原则”引申出了这一概念。框架是一个抽象实体，它是搭建应用 系统的基础所有的框架都应该独立于具体的应用系统，而一个显然易见的问题 就是应用系统中的业务对象之间肯定会存在依赖关系，但这些依赖关系又是具体 于应用系统的。如何在框架中将这种依赖关系抽象出来昵? 答案就是利用反向控 制l o c ( i u v c r s i o no f c o n 缸0 1 ) 的概念i o c 是一种让服务消费者不直接依赖于服务 提供者的设计方式，一种减少类与类之间相互依赖的设计原则。 m a r t i nf o w l e r 在其一篇经典文章( i n v e r s i o no fc o n t r o lc o n t a i n e r sa n dt h e d e p e n d e n c yi n j e c t i o np a t t e r n ) 中为i o c 取了一个更为贴切的名字：d e p e n d e n c y i n j e c t i o n 即依赖注入。在s p r i n g 框架中，b e a n 工厂就通过i o c 容器实现的依赖注 入来完成b e a n 的装配。 b 啪i d = ”d a t a s o u r c e ” i d a 硝= ”o 瑁栅，d l l g 弧w d r 】瞄n m j n 珊0 b j e c t f a c t o r y b e a n ” ，b e 趣n b 咖i d = ”s a m p l e d a o ”d 嬲s = ”n e t x i a x i n s p r i n g d a o s a m p l e d a o ”， p r o p e r t yn a m e = ”d a t a s o u r c e ”， 在这里，s a m p l e d a 0 中的d a t a s o u r c e 将由i o c 容器在运行时动态注入。 7 电子科技大学硕士学位论文 2 4 应用框架 应用框架并不是构建应用程序的小片程序，而是实现了某应用领域通用完备 功能( 除去特殊应用的部分) 的底层服务。框架提供了所有应用期望的默认行为 的类集合，具体的应用通过重写子类( 该子类属于框架的默认行为) 或组装对象来支 持应用专用的行为。应用框架强调的是软件的设计重用性和系统的可扩充性，以缩 短大型应用软件系统的开发周期，提高开发质量。与传统的基于类库的面向对象 重用技术比较，应用框架更注重于面向专业领域的软件重用。 应用框架将领域功能划分为多个相互协作又相互独立的模块即组件，组件的 变化不会相互影响。这样，开发人员只需关心菜一部分的应用实现，提高了开发 效率。应用系统不仅共享应用框架的组件的代码，更重要的是还共享了应用框架 的设计。虽然应用系统千差万别，但基于同一应用领域的应用系统却可以共享类 似的设计。开发人员不仅可以利用框架内的组件，还可以扩展框架来满足特定的 业务需求。这并不是说框架应该将所有的应用需求都考虑在内，这也是不可能做 到的，而是框架在设计过程中就应为开发人员提供可扩展的入口和方式。 应用框架还具有简单性的优点。应用框架通过封装控制流程而使开发人员获 得的简单性。如图2 1 所示，左边是典型的基于类库的应用，应用系统需要了解各 个组件之间的关系，并在应用中编写代码来控制。右边是基于应用框架的应用系 统，由于框架明确了各个组件之间的关系，应用系统的控制流程由应用框架来控 制。 广赢订 刨 应用蓉练 昏_ q ”应用摇架 i 徘# l- l 组件b 蛆件c i ，1 组件d i i 组件e l ll 组件， 图2 - i 类库和应用框架 8 第三章n e t 技术介绍 第三章n e t 技术介绍 n e t 框架分为两个部分：通用语言运行时c l r 和框架类库f c l 。在微软推 出n e t 平台的最初阶段，c l r 和f c l 还只能运行在各种版本的w m d o w s 系统中， 另外还有用于p d a 和各类家电产品的精简框架( n e t c o m p a c t f r a m e w o r k ) 。2 0 0 1 年，欧洲计算机制造商协会e c m a 正式接收了饼编程语言、部分的c l r 及部分 的f c l 作为其标准，这也意味着n e t 平台可以运行在各种操作系统和c p u 上了。 简而言之，n e t 平台为我们提供了以下一些服务： 一致的编程模型 我们知道，w m d o w s 平台通过动态链接库d l l 和c o m 组件来提供系统服务， 在n e t 托管环境中，所有这些应用程序服务都通过一致的、面向对象的编程模型 提供给开发人员。 简化的编程方式 c l r 的一个目的就是简化w i n 3 2 和c o m 环境下所需的各种复杂的基础结构， 除非要使用非托管环境编程要素，我们无需关心以前不得不面对的注腑表、g u l l ) 、 i u n k n o w n 、a d d r e f 等等概念。 可靠的版本机制 在n e t 之前，w i n d o w s 开发人员一定为“d l lh e l l ”所困扰，其根本原因在 于一个新的应用程序可能会覆盖以前版本的组件，从而使得其它依赖于旧组件的 应用系统无法正常运行。n e t 框架采用了一种新的版本机制，它确保一个应用程 序总能加载正确版本的组件。 无缝的语言集成 c o m 允许不同的编程语言进行互操作，n e t 框架则允许不同的语言之间进 行无缝的集成。只需遵循通用类型系统c t s 的规范，用v b 编写的组件可以在c 帮 中正常使用。 自动化的内存管理 在非托管与环境下，我们必须手动地指定类型的析构器来清理无用的内存， o 电子科技大学硕士学位论文 而由此可能产生的内存泄漏问题也相伴面生c l r 会自动进行资源管理，确保无 用内存单元的释放。 坚实的类型安全 在托管环境下，c l r 会确保所有代码都是类型安全的。例如，一个方法需要 一个4 字节的数组作为参数，则c l r 将会阻止我们传递给它一个8 字节数组。 3 1 反射( r e f l e o t i o n ) 反射，就是在运行时获得类型的元数据信息，如类型的方法、属性、构造器 等，从而利用这些元数据进行特定的操作。在非托管语言如c + + 中，内存就象一 个字节数组一样组织起来，如果声明一个3 2 个字节的数组，我们无从知道这3 2 个字节数据中到底有些什么。而在托管环境中，公共语言运行库加载器管理应用 程序域，这种管理包括将每个程序集加载到相应的应用程序域以及控制每个程序 集中类型层次结构的内存布局。c l r 因此也就知道了内存中的数据类型。 图3 - 1 n g r 反射模型 l e a f 框架中，反射的使用相当普遍，虽然反射会带来性能损耗，但却使应用 获得了高度的抽象和伸缩性。 1 0 第三章n e t 技术介绍 3 2 r e m o t i n g 由于企业应用大多是分布式架构，这就不可避免地要在不同的机器间传递数 据。在w i n d o w s 操作系统中，是将应用程序分离为单独的进程。这个进程形成了 应用程序代码和数据周围的一道边界。如果不采用进程闻通信( r p c ) 机制，则在 一个进程中执行的代码就不能访问另一进程，这是一种操作系统对应用程序的保 护机制。在某些情况下，我们可能需要跨过应用程序域，与另外的应用程序域进 行通信，即穿越边界。在本框架中，我们在d a t a p o r t a l 部分实现了一个r e m o t i n g 通道。什么是r e m o t i n g ，简而言之，r e m o t i n g 是程序或组件跨越边界进行交互的 过程，我们可以将其看作是一种分布式处理方式。从微软的产品角度来看，可以 说r e m o d n g 就是d c o m 的一种升级，它改善了很多功能，并极好的融合到n e t 平台下。r e m o t i n g 提供了一种允许对象通过应用程序域与另一对象进行交互的框 架。这也正是我们使用r e m o t i n g 的原因。 图3 屯r e m o t i n g 简单模型 r e m o t i n g 将客户端和服务器之间的通信划分为清晰的层次结构，首先，客户 端通过r e m o t i n g ，访问通道以获得服务端对象，再通过代理解析为客户端对象。 这就提供一种可能性，即以服务的方式来发布服务器对象。远程对象代码可以运 行在服务器上( 如服务器激活的对象和客户端激活的对象) ，然后客户端再通过 r e m o t i n g 连接服务器，获得该服务对象并通过序列化在客户端运行。获得了代理 对象之后，对服务端对象的调用请求就会通过r e m o t i n g 的各个层次传递到服务端 对象。请求被f o r m a t t e r 层序列化为一定的表示格式，如s o a p ，然后就交给t r a n s p o r t 1 1 电子科技大学硕士学位论文 通道层，遥过诸如t c p 、h t i p 这样类型的通道传递到服务端进程。在服务端进程 中，仍然会经过这些层作处理。最后，d i s p a t c h e r 调用服务端对象上相应的方法并 再次通过r e m o t i n g 来回传执行结果。 n e tr e m o t i n g 是一个相当开放的架构，我们可以扩展大多数层的功能，甚至 完全用自定义层替换它们。而这种扩展工作可以通过更改应用配置文件来完成， 这是相当方便的。在r e m o t i n g 中，对于要传递的对象，设计者除了需要了解通道 的类型和端口号之外，无需再了解数据包的格式。 3 3 范型( g e n e r i c ) n e t 2 0 相对于l 0 最大的变化奠过于范型技术的引入了，在1 0 时代，程序 员们肯定对数据的装箱和拆箱所带来的性能问题记忆犹新。为了获得数据操作的 通用性，我们不得不忍受频繁的装箱和拆箱操作。没有了装箱和拆箱，范型带来 了更为纯粹的通用性。 利用范型技术，就允许我们在类初始化时才获取到类中定义的类型规范。例 如，我们如下定义一个c u s t o m e r 范型类： p u b l i cd a s sc u s t o m e r t p u b l i cv o i da d d d e t a i l l t e m ( td e t a i l i t e m ) 值得指出的是，在将范型类作为基类时，必须指明t 的确切类型。只有当我 们实例化一个真正的c u s t o m e r 类型时，t 才会指定一个有意义的类型。在n e t2 0 框架中，范型的应用相当广泛。 前面我们介绍了n e t 提供的类型安全机制，但这种类型安全特性在使用集合 对象的n e t1 1 里消失了，因为集合可以容纳一切东西。但通过范型的使用，集合 1 2 第三章n e t 技术介绍 对象也具有了类型安全保证。使用范型的集合会保留集合的一般性质，但是在被 实例化的时候，通过为集合定义对象类型。 s y s t e m c o l l e c t i o n s g e n e t i c 命名空间含有用来定义范型集合的接口和类，它可 以让你创建强类型集合。反过来，它们提供了比非范型强类型集合更好的类型和 性能。 l i s t a l l s t = r e wl i s t o ； a i j s t a d d c 3 ) ； a i j s t a 眦( 4 ) ；