（应用数学专业论文）基于net的应用服务层框架的设计和实现.pdf

摘要 基于n e t 的应用服务层框架的设计和实现 专业：应用数学 硕士生：陈志勇 指导教师：伍小明副教授 摘要 在b s 架构的应用系统开发中，通常把系统分为用户界面层、应用服务层和 数据库层，其中应用服务层是整个系统的核心，它还可以细分为数据存取层、实 体控制层、业务逻辑层和业务外观层四个层次。由于应用服务层的复杂性，在开 发过程中很容易造成模块的紧密耦合；并且由于各种应用具有一定的相似性，如 果都从底层开始构建应用服务层，就会导致大量重复的劳动。框架为实现代码重 用、设计重用以及分析重用提供了很好的技术支持，能够规范开发过程、降低开 发成本和提高产品的质量。 本文系统地对应用服务层进行了分析，在n e t 平台上设计并实现了应用服务 层的框架。本文首先对j a v a 和n e t 平台上的开发框架发展状况进行介绍，明确 在应用服务层上建立开发框架的必要性。然后对应用服务层的四个子层进行详细 分析，并提出应用服务层框架的总体设计思想，接着以模块为单位详细介绍应用 服务层框架的具体设计和实现。最后本文给出了一个使用应用服务层框架的开发 实例，以检验框架的可用性。 本文实现的应用服务层框架基本上实现了面向实体对象的持久化机制，并支 持业务逻辑的解藕、业务撤销和业务规则的检查；此外本文还提出了使用接口作 为实体类的属性承载体的思想，可以达到减少冗余代码的效果。 关键词：应用服务层，框架， n e t ，o r m ，a o p 英文摘要 d e s i g na n di m p l e m e n t a t i o no ff r a m e w o r k f o r a p p l i c a t i o ns e r v i c et i e r o n n e t m a j o r ：a p p l i e dm a t h e m a t i c s a u t h o r ： z h i y o n gc h e n d i r e c t e db y ：a s s o c i a t ep r o f e s s o rx i a o m i nw u a b s t r a c t i nt h ef i e l do fb r o w s e r s e r v e rm o d ea p p l i c a t i o ns y s t e md e v e l o p i n g ，w eu s u a l l y d i v i d ef h es y s t e mt ot h r e et i e r s ，w h i c ha r eu s e ri n t e r r a c et i e r , a p p l i c a t i o ns e r v i c e t i e ra n dd a t a b a s et i e r t h ea p p l i c a t i o ns e r v i c et i e ri sc e n t e ro ft h ew h o l es y s t e m ， a n dc a nb es p l i t e dt of o n rs u bt i e r s ，w h i c ha r ed a t aa c c e s st i e r e n t i t ym a n i p u l a t i o n t i e r b u s i n e s sl o g i ct i e ra n db u s i n e s sf a c a d et i e ld b et ot h ec o m p l e x i t yo ft h e a p p l i c a t i o ns e r “c et i e r , i ti se a s yt oc o u p l em o d u l e sw h i c hs h o u l db eb u i l ts e p a r a t e l y a l t h o u g ha p p l i c a t i o ns y s t e m sa r ed i f f e r e n t ，t h e r ea r es t i l ls o m es i m i l a r i t yi nt h e a p p l i c a t i o ns e r v i c et i e r , t h e r e f o r et h e r ew i l lb el o t so fd u p l i c a t ec o d ei fw eb u i l d s y s t e mf r o mt h eb a s i s f r a m e w o r ki sau s e f u lt o o lt os u p p o r tc o d er e u s e d e s i g nr e u s e a n da n a l y s i sr e u s e ，a n di tc a nf o r m a l i z et h ed e v e l o pp r o c e d u r e ，r e d u c et h e s to f d e v e l o p i n ga n di m p r o v ep r o d u c tq u a l i t y t h i st h e s i sa n a l y z e st h ea p p l i c a t i o ns e r v i c et i e r , a n dd e s i g n saf r a m e w o r ko f a p p l i c a t i o ns e r v i c et i e ri n n f r f i r s t l y , i ta n a l y z e st h ed e v e l o p m e n to ff r a m e w o r k i nj a v aa n d n e tp l a t f o r m a n dd e f i n i t i z e st h en e c e s s i t yo fb u i l d i n gf r a m e w o r kf o r a p p l i c a t i o ns e r v i c et i e ls e c o n d l y , i ta n a l y z e st h ef o u rs u bt i e r so fa p p l i c a t i o n s e r v i c et i e ra n dg i v e st h eg e n e r a ls t r u c t u r eo ft h ef r a m e w o r k t h e ni ti m p l e m e n t st h e f r a m e w o r kb yt h es e q u e n c eo fs u bt i e r s f i n a l l y , i tg i v e sa ni n s t a n c ew h i c hu s e st h i s f i r a m c w o r k ，a n dc h e c k st h eu s a b i l i t y t h ef r a m e w o r kf o r a p p l i c a t i o n s e r v i c et i e rr e a l i z e sa n o b j e c t o r i e n t e d p e r s i s t e n c em e c h a n i s m ，a n ds u p p o r t ss e p a r a t i n gc o u p l i n gm o d e l ，r o l l i n gb a c kb u s i n e s s c h a n g ea n dc h e c k i n gb u s i n e s sr u l e s t h ef r a m e w o r ku s e si n t e r f a c ei n s t e a do fc l a s st o d e n o t et h ee n t i t y , r e d u c i n gd u p l i c a t ec o d e k e y w o r d s ：a p p l i c a t i o ns e r v i c et i e r , f r a m e w o r k , n e t , o r m ，a o p 1 1 i 第一章综述 第一章综述 1 1 软件体系结构的发展 1 1 1 两层的c l s 体系结构 在传统的应用系统的开发领域中，c s ( c l i e n t s e r v e r ) 体系结构得到了广泛 的应用，在w e b 和i n t r a n e t 技术还没有大量走进市场的前几年里，c s 技术也曾 经帮助了世界各地的公司和企业提高了工作效率。 基于d s 体系结构的系统是一种两层结构的系统：第一层在客户机系统上处 理界面显示和业务逻辑；第二层是通过网络连接数据库服务器。它把用户界面和 业务处理跟数据库的访问相分离，服务器与客户端之间通过消息传递机制进行对 话，由客户端发出请求给服务器，服务器进行相应的处理后经传递机制送回客户 端【2 1 。 c s 结构存在着很多系统结构上的问题，例如当客户端数目激增时，服务器 端的性能会因为负载过重而大大减弱；如果应用的需求发生变化，则客户端和服 务器端都需修改，造成极大的不便；由于部分数据的处理需要在客户端进行，因 此会产生大量的数据传输，增加网络负担等等【2 1 。 1 1 2 三层的b s 体系结构 随着i n t e m e t i n t r a n e t 技术的不断发展，尤其是基于w e b 的信息发布和检索 技术，导致了整个应用系统的体系结构从c s 结构向灵活的多级分布式结构演 变，这一演变给体系结构在当今以w e b 技术为核心的信息网络的应用赋予了新 的内涵，这种新型的多级分布式结构就是浏览器服务器( b r o w s e r s e r v e r ) 系统。 b ，s 架构应用系统由浏览器和服务器组成。数据和应用程序都存放在服务器 上，浏览器功能可以通过下载服务器上的应用程序得到动态扩展，服务器具有多 基于n e t 的应用服务层框架的设计和实现 层结构，b s 系统处理的数据类型可以动态扩展。以b s 模式开发的系统维护工 作集中在服务器上，客户端不用维护，操作风格比较一致，只要有浏览器的合法 用户都可以十分容易地使用【3 】o 与c s 体系结构相比，基于b s 体系结构开发的应用系统一般具有以下三层 结构【4 】： 用户界面层 应用服务层 数据库层 图1 - 1b s 架构应用系统的三层结构 三层的b s 体系结构的特点是在传统的两层应用结构中的客户端与服务器 之间插入一层应用服务层，应用服务层处理应用系统的业务逻辑，客户端程序只 需处理界面的显示，并由应用服务层与数据库通讯。因为客户端不需要与数据库 通讯，所以不需要安装数据库的客户端程序和数据库驱动程序，可以使客户端程 序变得更小，更快。总的来说，三层的b s 体系结构具有以下优势1 5 1 ： 1 ) 瘦客户端。客户端应用程序可以写得很小，而把大多数工作交给应用服 务器处理。由于不需要考虑安装，配置和维护数据库连接软件等的问题，客户端 应用程序变得更加容易发布，所有的配置和维护工作只需在服务器端做好即可。 2 ) 分布式数据处理。可以将一个应用系统的工作分布到几台机器上以改善 系统的性能，并且可以使用多台服务器协同运作得到高性能服务器的效能，减少 了系统部署的开支。 3 ) 增强安全性。可以通过使用不同的访问约束，来分层隔离对敏感的功能 的访问。应用服务层可以限制敏感部分的入口点，这样可以更加容易地对服务器 的访问进行控制。 1 1 3 多层的体系结构 第一章综述 b s 体系结构中的应用服务层作为一个中间层，是整个应用系统的核心所在。 它主要负责业务逻辑的组织和提供，并且对业务处理过程中的数据进行计算和存 储等操作。事实上，由于应用服务层的复杂性，仅仅把应用服务层视为一个最小 化的层次进行开发往往会造成设计混乱的后果。例如在构建b s 架构的应用系统 时，开发人员很可能会受到传统两层的c s 模式的影响，把数据库操作、业务逻 辑处理甚至界面显示夹杂在一起，或者把业务逻辑处理等同于数据库操纵等等， 这些做法都会造成系统结构的混乱，代码的职能不明确，对系统的升级和维护都 会带来不便【6 j 。 目前的应用系统开发中提倡一种多层次性的结构，把复杂的层次再进行细 分，使得每层仅完成自己独立的功能，减少应用系统的耦合性。为了使应用服务 层的设计达到最好的效果，通常还需要对应用服务层作进一步的职能分析和层次 细分。实际上，应用服务层可以再被细分为四个层次：数据存取层、实体控制层、 业务逻辑层和业务外观层1 6 】，如图1 2 所示 用户界面层 业务外观层 j 业务逻辑层 实体控制层 l 数据存取层 数据库层 图卜2 应用服务层的细分 这四个层次的主要功能如q r 6 1 ： 1 ) 数据存取层主要负责应用系统与数据库的交互，根据实体控制层中提供 的s o l 语句对数据库进行g r u d ( g e t ，r e a d ，u p d a t e ，d e l e t e ) 操作，并把结果返 基于n e t 的应用服务层框架的设计和实现 回实体控制层。 2 1 实体控制层主要负责数据实体的持久化操作。在应用系统中，数据是处 理的基本对象，程序总是以一定的数据结构来表现数据，例如在使用面向对象语 言开发的系统中，复杂的数据总是以类和对象的形式表现出来。实体对象是数据 在内存中的表现形式，当对象的活动周期结束( 例如内存清空或应用系统关闭等) 时需要保存对象的内容以便在下次需要该对象时能够对其进行激活并重新进入 活动周期，也就是对象的持久化。实体控制层控制数据实体的状态，并提供一种 对象持久化的机制。 3 1 业务逻辑层负责系统的业务逻辑处理，是应用软件系统的核心部分，它负 责组织各种实体对象，并将它们进行组合以构建业务处理类，并使用业务处理类 对系统的业务逻辑进行处理。 4 ) 业务外观层负责业务逻辑与用户界面层的交互。业务逻辑根据用户的输入 进行处理，并把处理结果输出给用户。在业务逻辑层和用户界面层间增加一个业 务外观层处理交互的操作，并且为各种异构的用户界面层解决方案提供一个统一 的接口，这样业务类就只需专心于处理业务逻辑，而把输出输入的工作交给业务 外观层处理。 1 2 应用系统的开发框架 框架是可重用的、“半成品”应用程序，开发人员可以在它的基础上开发特 定的应用程序。与早期基于类库的面向对象重用技术不同的是，框架针对特定的 商业处理单元或应用领域而设计。框架由组件的集合构成，这些组件为解决目标 领域问题提供了可重用的体系结构。利用这个可重用的体系结构，使得这些问题 的解决变得十分容易【7 j a 1 2 1 开发框架的优点 框架可以给使用框架的开发人员提供三个方面的好处【8 l ： 1 ) 模块性 框架使用稳定的接口封装了框架的具体实现，从而增强了框架的模块性。框 第一章综述 架使用这种机制将具体实现的影响和实现的改变局部化，从而提高了软件产品的 质量。局部化的好处在于减少了理解和维护具体实现的时问和金钱。 2 ) 可重用性 通过框架提供的稳定接口增强了软件产品的可重用性。当创建新的应用程序 时，可以重用框架中定义的通用组件。这些通用组件由具有丰富领域知识和程序 设计经验的程序员设计开发，能满足应用领域的需求。使用通用组件避免了软件 产品中这些部分重新设计带来的麻烦。可重用的框架组件的使用也相应的提高了 程序员开发软件产品的效率，同时又保证了软件产品的质量、性能、可靠性。 3 1 扩展性 框架通过提供一种“钩子”( h o o k ) 方法提高它的扩展性，这些方法允许应用 程序扩展框架稳定的接口，它将稳定的接口和特定应用中可变的行为分离开来。 框架的这种特性保证了框架能够方便地支持新的应用。 1 2 2j a v a 平台上的开发框架 j a v a 经过了1 0 年的发展渐渐趋向成熟，由于它具有可以跨平台使用的特性， 不少的开发人员都热衷于使用j a v a 进行应用系统的开发。在j a v a 平台上有许多 成熟的开发框架，并且由于它们很多是开源的，因而发展速度很快【9 1 。目前j a v a 平台上比较著名的开发框架有： 1 ) h i b e r n a t e ：h i b e r n a t e 是一个开放源代码的对象关系映射框架，它对j d b c 进行了轻量级的对象封装，使得j a v a 程序员可以方便地使用面向对象编程的思 维来操纵数据库【1 0 1 。 2 ) s p r i n g ：s p r i n g 是一个解决了许多在j 2 e e 开发中常见的问题的强大框架。 s p r i n g 提供了管理业务对象的一致方法，并且鼓励注入对接1 2 1 编程而不是对类编 程的良好习惯。s p r i n g 的架构基础是基于使用j a v a b e a n 属性的i n v e r s i o no f c o n t m l 容器。s p r i n g 提供了用标准j a v a 语言编写的a o p ( 面向方面编程) 1 3 1 框架，它给p o j o s 提供了声明式的事务管理和其他企业事务【1 2 1 。 3 ) s t r u t s ：s t m t s 是一个基于j 2 e e 平台的m v c ( m o d e l ，v i e w , c o n t r 0 1 ) 框架， 主要是采用s e r v l e t 和j s p 技术来实现的，开发人员利用其进行开发时不用再自 己编码实现全套m v c 模式，极大的节省了时间i “】。 基于n e t 的应用服务层框架的设计和实现 a s p e c t j ：a s p e c k l 是一个面向方面编程的框架，它扩展了j a v a 语言并定义 了a o p 语法，提供了主关注点和横切关注点的无缝集成1 3 ”。 l - 2 3 n e t 平台上的开发框架 与j a v a 平台相反的是，n e t 平台中成熟的开发框架并没有j a v a 平台上多， 这其中一方面是由于n e t 发展的时间不长，还处于渐渐成熟的过程中，另一方 面是由于n e t 对跨平台的支持并不如j a v a 良好，而且许多n e t 的核心技术都 只掌握在微软的手中。即便如此，n e t 平台上也有一些比较好的开发框架： 1 ) n h i b e m a t e ：n h i b e r n a t e 是一个基于n e t 的针对关系型数据库的对象持 久化类库。n h i b e r n a t e 来源于非常优秀的基于j a v a 的h i b e r n a t e 关系型持久化工 具。n h i b e r n a t e 从数据库底层来持久化n e t 对象到关系型数据库。开发过程中 代码仅仅和对象关联，n h i b e m a t 自动产生s o l 语句，并确保对象提交到正确 的表和字段中去【1 4 】。 2 ) s p r i n g n e t ：s p r i n g n e t 是对s p r i n g 工具从j a v a 平台向n e t 平台的完 全移植。它在a o p 的实现上与s p r i n g 几乎完全相似，仍然利用了a o p 联盟提 供的拦截器、a d v i c e 等实现a o p 。s p r i n g n e t 的配置文件也与s p r i n g 相同【1 5 】。 1 3 n e t 技术 n e tf r a m e w o r k 是m i c r o s o f t 整个n e t 策略的核心，它是由一组统一的类 库，服务和开发工具构成，用来克服已有的编程模型的限制。 n e tf r a m e w o r k 设计的目标是【1 6 l ： 1 ) 为因特网和分布式应用程序的开发提供一个新的开发平台。 2 ) 简化应用程序开发和部署。 3 ) 为构建w e b 服务提供一个标准平台。 4 ) 改善系统和应用程序的交互性和集成性。 n e tf r a m e w o r k 由层次化的服务、类和工具组成，这些服务、类和工具完 美地组合在一起而形成了全新的n e t 开发平台。n e t 结构分为三个主要的子 第一章综述 集：公共语言运行时( c o m m o nl a n g u a g er u n t i m e ，c l r ) 、n e t 框架类库和语言 及开发人员工具。图1 3 是n e tf r a m e w o r k 的结构图， 亟堕 巫亘 数据和x m l 基本类库 公共语言运行时 图卜3 n e tf r a m e w o r k 结构图 以下对部分n e tf r a m e w o r k 中的技术作简要的介绍。 1 3 1 元数据和反射 元数据( m e t a d a t a ) 是指描述数据的数据，因为c l r 本质上是面向对象的， 所以在元数据中表示的项是类、属性( p r o p e n y ) 和关系。 使用元数据可以允许n e t 在运行时刻知道要分配的类型以及要调用的方法， 这样运行环境就可以设置得更有效，以便应用程序运行，查询元数据的这种方式 就叫做反射( r e f l e c t i o n ) ，反射具有在运行时发现类型信息的能力i 。 s y s t e m r e f l e c t i o n e m i t 命名空间的类提供了一种特殊形式的反射，使用户能 够在运行时发出( e m i t ) 元数据和中间语言( i n t e r m e d i a t el a n g u a g e ，i l ) 创建动 态程序集，并可选择在内存中或磁盘上存放生成的动态程序集【1 7 】。 1 3 2 特性 由于编译器被设计为识别预定义关键字，因此用户没有机会创建自己的关键 字。为了让用户可以使用类似于关键字的自定义描述，公共语言运行库允许用户 添加特性( a t t r i b u t e ) 来批注类型、字段、方法和属性等编程元素【1 9 】。 为运行库编译代码时，该代码被转换为中间语言，并同编译器生成的元数据 一起被放到可移植可执行( p e ) 文件的内部。用户可以使用特性向元数据中放置 额外的描述性信息，并使用反射机制提取该信息。使用特性可以解决很多问题， 基于n e t 的应用服务层框架的设计和实现 例如描述如何将数据序列化和描述具有强制安全性的方法等。 所有的特性都是从s y s t e m a t t r i b u t e 派生，并且以a t t r i b u t e 为名称结尾f 例如 o b s o l e t e a t t r i b u t e ) 的类。系统自带的特性和用户定义的特性的使用方法是一样的， 只需在所引用的程序元素的上一行中，使用方括号包围特性声明的代码即可，可 以使用逗号分隔多个特性。在声明特性时，特性类的后缀a t t r i b u t e 可以省略， 系统会自动地为特性的声明补充a t t r i b u t e 后缀1 2 0 】。 1 3 3a d o n e t a d o n e t 提供对m i c r o s o f ts q ls e r v e r 和o r a c a l 等数据源的一致性访问，应 用程序可以使用a d o n e t 连接到这些数据源，并执行查询、插入、更新和删除 数据的操作。 a d o n e t 有效地将数据访问分解为多个可以单独使用的组件，它包含用于 连接到数据库、执行命令和检索结果的数据连接类，用户可以直接处理检索到的 结果，或将其放入a d o n e td a t a s e t 对象中，以便与来自多个数据源的数据或 在层之间进行远程处理的数据组合在一起。d a t a s e t 对象也可以独立地使用，以 管理应用程序本地的数据或源自x m l 的数据【2 l 】。 图1 - 4 是a d o n e t 的体系结构图，包括d a t a s e t 和n e t 数据提供程序两个 核心组件瞄 d 3 f 日辩i 1 n e t 鼓绺羟供氍印 d a t a a d a p t e r | ) 4 i a l a b i c c o i l c c i 0 1 1 | c o n n e c “o n 【t 捧符i l s cj “l c o m n d i d a t a t 3 b t e li n s c r l c o ，n n a n dj ld a l a 靶o w c 州i c c l i o i li l 鍪敬i d c l c t c c o m n a n d i id a l a c o l u m n c o l l e e t i o ni ic o n s t r a i n t c o l l e c t i o nl d a t 8 d e r1 u p d a t c c o n l h a n d | i j a | 8 k cj a l l o r l k u i # c n l 旧 0士 图卜4a d o n e t 体系结构图 1 3 4w e b 服务 第一章综述 w e b 服务是建立可互操作的分布式应用程序的新平台，其主要目标是通过向 外界提供能够通过w e b 调用的a p i ，实现跨平台的互操作。w e b 服务允许应用 程序通过i n t e m e t 进行通讯和共享数据，而不管所采用的是哪种操作系统、设备 或编程语言【2 2 1 。 在使用w e b 服务时，有几个开放式标准技术起着重要的作用。这些标准可以 按描述、发现和传输进行分类【2 4 】： 1 ) 描述w e b 服务描述语言( w e bs e r v i c ed e s c r i p t i o nl a n g u a g e , w s d l ) 是一种基于x m l ( 可扩展标记语言) 的标记语言，用来描述w e b 服务方法、程 序传递给方法的参数以及方法的返回值类型等信息。 2 ) 发现通用描述发现和集成( u n n e m a ld e s c r i p t i o nd i s c o v e r ya n d i n t e g r a t i o n ，u d d i ) 目录支持发现。这些目录管理w s d l 文档并提供客户端查找和 使用w e b 服务的手段。 3 ) 传输简单对象访问协议( s i m p l eo b j e c ta c c e s sp r o t o c o l ，s o a p ) 是使 客户端与u d d i 目录和w e b 服务交互的通信协议。s o a p 是一个覆盖在h t r p 等协议的开放式标准协议，该协议包装了一个方法调用到包中以便在端点之间传 递。 开发和运行环境中的w e b 服务如图1 5 所示： 发现 3 八代 应用 开发者 圄墨目 ljl 一，。 闰卜5 开发和运行环境中的b 服务 基于n e t 的应用服务层框架的设计和实现 1 3 5 泛型 泛型是n e tf r a m e w o r k2 0 的新功能。泛型将类型参数的概念引入n e t f r a m e w o r k ，类型参数可以把类或方法中的类型推迟到实例化的时候指定。 使用泛型可以重用代码、保护类型的安全以及提高性能。对于值类型而言， 以前使用a r r a y l i s t 保存时需要经过装箱( b o x ) 和拆箱( u n b o x ) 的操作，对效 率造成影响；使用泛型类l i s t 保存值类型后，可以免除装箱和拆箱的操作并 提高了性能。此外，使用泛型可以创建泛型类，泛型方法，泛型事件( e v e n t ) 和泛 型委托( d e l e g a t e ) ，把一些类似的类或方法等用泛型来组织可以到达减少代码的 效果【矧。 1 4 本文的研究内容 1 4 1 问题的提出 根据前面对多层体系结构的分析可以知道，应用服务层是一个复杂而又重要 的层，从底层开始构建应用系统很容易会造成代码混乱和层次不清晰，因此很有 必要使用开发框架来简化和规范对应用服务层的开发。目前的各种开发框架中， 大部分是针对各种细分层次构建的，例如j a v a 平台上的h i b e r n a t e 是面向持久层 开发的框架，这样在开发应用服务层时就难免需要对各种开发框架进行整合，从 而带来额外的工作量，而且整合的过程中还可能出现冲突的问题。事实上，应用 服务层是一个统一的整体，因而构建一个统一的应用服务层框架是有必要的。 1 4 2 本文的工作 本文对应用服务层进行分析，并构建了一个应用服务层框架a s n e t 。 a s n e t 根据应用服务层的分层结构分成四个模块，其中a s d a t a a c c e s s 模块对 应于数据存取层，a s o r m 模块对应于实体控制层，a s a o p 模块和a s b u s i n e s s 模块对应于业务逻辑层，并且使用w e b 服务作为业务外观层使各种异构的用户 第一章综述 界面层都可以使用相同的业务逻辑。 a s n e t 利用n e tf r a m e w o r k2 0 中的泛型和e m i t 机制提出一种简化的实体 类表示方式，使用接口来作为实体类的属性承载体，然后在运行过程中动态产生 实体类，并且这个动态实体类具有比较多的功能，例如支持可序列化 ( s e r i a l i z a b l e ) 和可创建副本( c l o n a b l e ) 的机制，可以嵌套其他的动态实体类 以表达复杂的结构等，从而达到减少传统实体类定义方法中的冗余代码的效果。 a s n e t 能够支持面向实体对象的g r u d 操作，开发人员只需要对持久化对 象发送s a v e 、g e t 、d e l e t e 等命令就可以完成对象的保存、获取、删除等工作， 并且提供了对事务的简单支持。 在业务逻辑的处理上，a s n e t 提供可以灵活使用n e tr e m o t i n g l 4 2 域者动 态代理( d y n a m i cp r o x y ) 1 4 1 1 两种动态织入方式的a o p 功能，并且提供统一的调 用界面让开发人员方便地在这两种方法上转换。除此之外，a s n e t 还实现了业 务撤销和业务规则检查的功能。 a s n e t 大部分模块采用特性进行配置，可以减少使用外置配置文件有可能 带来的定位错误点困难的麻烦。 1 4 3 本文的组织 本文在第一章首先介绍软件体系结构的发展，然后概述j a v a 和n e t 平台上 的开发框架发展状况，并对n e tf r a m e w o r k 的部分机制进行简单的介绍。 第二章简要概述应用服务层需要处理的问题，并对应用服务层的各个层次进 行详细的分析。 第三章分析在n e t 上建立应用服务框架的设计目标和原则，并对应用服务 层框架进行总体设计。 第四章按照应用服务层的分层结构，对应用服务层框架进行详细的设计和实 现。 第五章使用应用服务层框架对某个学院院务办公自动化系统的教学进程管 理模块进行重新设计，以验证该应用服务层框架的可用性。 本文最后对所做的设计与开发工作进行总结，并阐述将来进一步的扩展与完 善此开发框架需要做的工作。 第二章应用服务层的具体分析 第二章应用服务层的具体分析 本章简要概述应用服务层需要处理的问题，并对应用服务层的各个层次进行 详细的分析，为下文的应用服务层框架的实现提供了设计基础。 2 1 应用服务层处理的问题 应用服务层是应用系统的核心部分，它集中处理系统的业务逻辑。虽然不同 领域的应用系统其应用服务层的实现不相同，但是有一些问题是各种应用系统都 需要解决的，主要包括以下问题： 1 ) 数据实体的表示 在面向对象的系统中，数据是用类来表示的，这个类代表了现实世界实体对 象在软件系统中的抽象。应用系统通常会使用数据库，可以把数据库中的数据看 成是对象的持久化保存。由于目前关系数据库已经广泛流行，而面向对象数据库 技术尚未成熟，因而绝大多数系统都采用关系数据库【2 6 1 。当构建一个具有大量 业务逻辑的应用系统时，使用面向对象的方法组织数据是有好处的，但是关系数 据库并不能支持面向对象中的继承等重要的机制【明。因此在开发应用系统时出 现了系统开发使用面向对象方法，而在数据存储中使用不支持面向对象的数据库 的矛盾。为了解决这个矛盾，需要考虑类( 对象) 与关系型数据的映射，即通常 所说的对象一关系映射问题。 2 1 数据持久化的服务 在对象的活动期结束后，需要对对象执行持久化操作，以便以后能够方便地 激活并使对象重新进入活动期。通常使用数据库作为对象持久化的载体，因此应 用服务层必须处理同数据库的交互操作，以及数据的存取和转换等问题。数据持 久化服务封装了数据存储、读取和删除等的操作，开发人员不需要写s q l 语句， 甚至不需要知道使用的数据库，只需要调用持久化操作的方法即可执行数据实体 持久化操作，从而达到全面使用面向对象方法开发系统的目的。 3 1 业务逻辑的组织 在面向对象的系统中，业务逻辑表现为对象之间的交互。有了上述的实体对 基于n e t 的应用服务层框架的设计和实现 象，以及对象的保存策略，就可以将这些对象组合起来，编写业务逻辑处理程序， 并且通常把业务逻辑封装成组件的形式以得到最大的可重用性。然而，虽然面向 对象的编程模型有效的缩短了分析和设计之间的鸿沟，但是也有一些问题很难甚 至不可能使用传统的结构( 例如组件、对象或者过程) 以一种清晰的，局部化的 方法表述【3 l 】。例如安全控制的问题，如果把许多小的代码片断添加到大多数已 有的组件或对象中，当安全控制的策略需要更改时，则需要把各个业务逻辑中的 安全控制代码作更改，可能会破坏原有良好的、清晰的系统设计，并且这种代码 分散的设计也不是良好的设计。为了解决这些问题，开发人员需要在应用服务层 中构建一种结构良好的机制组织业务逻辑类。 4 1 服务提供方式 完成应用服务层的基本功能后，一个需要考虑的问题是如何向软件的使用者 ( 调用的界面、其他程序等) 提供服务。例如，在一个基于w e b 的a s e n e t 系统 中，使用应用服务层的客户就是系统的a s p n e t 页面。业务逻辑组件应该通过 什么方式，或直接或间接向这些客户提供服务，是在构建应用服务层时需要处理 的问题。 2 2 应用服务层各子层的分析 2 2 1 数据存取层 数据存取层主要负责应用系统对数据库进行的g r u d 操作。目前主流的关系 型数据库系统有多种，如a c c e s s 、s q l s e r v e r 、o r a c l e 和d b 2 等，不同的数据库 系统的实现策略和给用户调用的接口是有差异的，当更改数据库系统时，可能需 要对整个应用系统的数据库操作代码进行更改。 然而，尽管不同的数据库在使用时有差异性，但是所有的关系型数据库都在 一定程度上支持s q l 标准，这为在应用服务层中建立一个与数据库系统无关的 数据存取层提供实现的基础。 数据存取层应能屏蔽底层数据库的差异性，对各种烦琐的数据库连接、控制、 读取和写入等操作进行封装，并能提供一系列统一的、方便使用的接口供上层模 块调用。 2 2 2 实体控制层 第二章应用服务层的具体分析 在各种业务逻辑的处理过程中，业务逻辑模块会产生大量的数据，这些数据 有些是暂时的，当业务逻辑处理结束后可以丢弃；但是更多的数据需要被保存起 来以便日后可以把数据读取出来进行再处理。 目前常用的数据保存的策略主要有两种【明： 1 1 使用x m l 文件进行保存：x m l 是结构化的，能够方便地对数据进行组 织和处理，但是其载体是文本文件，因而大规模数据的存取速度是不能另人满意。 孙使用数据库系统进行保存：数据库系统对数据的组织和处理提供了良好的 支持，并且由于数据库中提供了各种优化存取的机制，能够有效地解决读取文本 文件效率不高的问题。 常见的数据库系统可以分为关系型数据库系统和面向对象数据库系统。在使 用面向对象方法开发应用系统时，业务逻辑中的数据表现为数据实体，因而理想 的数据库系统应该为面向对象数据库系统，然而目前成熟的面像对象数据库并不 多，而且面向对象数据库目前尚无完备的理论基础和实现标准，只是处于实验阶 段，有些面向对象数据库的实现是扩充关系模型的半关系半面向对象数据库【圳。 而关系数据库是一种比较成熟的数据库技术，并且它是建立在严密的数学逻辑上 的，具有坚实的理论基础，现在实用的数据库系统大多数都是建立在关系模型之 上的，因此使用关系数据库来保存数据无疑是最常用和最可靠的办法。由于关系 模式和面向对象模式的不一致性，引伸出了一个在面向对象的系统设计中的问 题：对象关系映射( 0 b j c c t r e l a t i o nm a p p i n g ，o r m ) t 州。 o r m 的实质就是将关系数据库中的数据用对象的形式表示出来，并通过面 向对象的方式将这些对象组织起来。对面向对象而言，数据库不应该和业务逻辑 绑定到一起，o r m 则起到这样的分离作用，它使数据库层透明，而开发人员则 能真正地面向对象。 基于n e t 的应用服务层框架的设计和实现 图2 - 10 p , m 在多层系统框架中的作用 o r m 在关系数据表和对象之间作一个映射，使开发人员在操作数据库时不 需编写复杂的s q l 语句，只需像平常操作对象一样即可完成g r u d 操作。o r m 使用元数据描述对象和数据表之间的映射关系，并通过读取这些映射信息将程序 中的对象持久化到数据表中，其本质就是在面向对象开发中将数据在运行时形态 和持久化形态之间相互转换。 o r m 可以减少开发系统过程中不必要的重复工作。当不使用o r m 开发一个 应用系统时，开发人员除了需要写不少数据存取层的代码执行g r u d 操作外， 也要写很多的方法完成读取对象数据，改变状态对象等等的任务，从而造成了很 多冗余代码，并给系统的维护带来麻烦。使用o r m 后，它会自动帮助开发人员 生成数据访问的代码，开发人员仅仅需要关心对象即可。 2 2 3 业务逻辑层 业务逻辑层负责处理所有的业务逻辑处理请求，并把处理结果通过业务外观 层返回，并在用户界面层显示。业务逻辑层还需要提供执行业务的规则，为具体 应用提供事务处理、安全控制以及进行性能调整等功能。 业务逻辑是比较复杂的，不同的应用系统的业务逻辑也十分不同，因而很难 对其提供一个统一的处理框架，只能针对各个领域分别建立不同的框架。然而， 在使用面向对象方法建立各种业务逻辑的时候，由于面向对象设计的本质是静态 的，封闭的，任何需求的细微变化都可能对开发进度造成重大影响。当人们进行 软件开发时，会发现面向对象方法很难清晰的捕捉所有的设计时的决策。 第二苹应用服务层的具体分析 例如，在设计一个应用系统时，设计人员已经从一个良好的、清晰的系统设 计开始，把所有重要的领域概念都清晰地表示为对象或者组件。随后，需求或者 非功能需求开始变更，例如：客户要求系统应该是在网络上分布并运行的。为了 这个目的，必须添加一些对新问题的支持，这些问题包括安全控制，事务控制， 分布数据传输，以及同步并发访问和执行。实现每个这样的问题都需要把许多小 的代码片段添加到大多数已有的组件或者对象中，甚至必须修改整个组件结构， 以获得所需的性能。做出所有这些更改后，基本上摧毁了原有的良好的、清晰的 系统设计。通常称这些难以使用传统的模块化结构局部化的问题为横切关注点， 并且认为这些问题横切了模块化的结构【3 2 】。 业务逻辑l业务逻辑2业务逻辑3 安全控制 日志记录 图2 - 2 业务逻辑中的横切现象 横切问题会对应用系统的设计带来一系列的问题，主要可以分成两类【3 3 】： 1 1 代码混乱：软件系统中的模块可能要同时兼顾几个方面的需要。例如，开 发人员经常要同时考虑业务逻辑、性能、同步、日志和安全等问题，兼顾各方面 的需要将导致相关联的实现代码同时出现，引起代码的混乱。 2 1 代码分散：由于横切关注点本来就涉及到多个模块，相关实现也就得遍布 在这些模块里，导致横切关注点的代码分散在各处。 使用面向方面编程( a s p e c to r i e n t e dp r o g r a m m i n g ，a o p ) 可以很好地解决这些 代码横切的问题。a o p 是施乐公司帕洛阿尔托研究中心( x e r o xp a r c ) 发明的 一种编程范式。由于软件系统越来越复杂，大型的企业级应用越来越需要人们将 核心业务与公共业务分离。a o p 技术正是通过编写横切关注点的代码，即“方 面”，分离出通用的服务以形成统一的功能架构。它能够将应用程序中的商业逻 辑同对其提供支持的通用服务进行分离，使得开发人员从重复解决通用服务的劳 基于n e t 的应用服务层框架的设计和实现 动中解脱出来，而仅专注于企业的核心业务逻辑。因此，a o p 技术也就受到越 来越多的关注，而应用于各种平台下的a o p 技术也应运而生。但由于a o p 技术 相对于成熟的面向对象技术而言，在性能、稳定性、适用性等方面还有待完善， 同时a o p 技术也没有形成一个统一的标准，这使得a o p 技术的研究更具有前沿 性的探索价值1 3 ”。 a o p 主要包括以下的概念川： 1 1 方面( a s p e c t ) ：关注点的模块化实现，这个关注点的实现可能横切另外多 个对象，例如j 2 e e 中的事务管理是应用横切关注点的一个很好的例子。 2 ) 连接点( j o i np o i n t ) ：连接点是主代码中一个定义明确的位置，关注点将在 这里横切应用程序。连接点可以是方法调用、构造函数调用、异常处理程序，或 者程序执行中的其他点。 3 ) 通知( a d v i c e ) ：在特定