（计算机软件与理论专业论文）基于反射机制的轻量级java持久层框架设计与实现.pdf

摘要 目前，关系数据库仍然是使用最为广泛的存储持久化数据的方式。在j a v a 中，有许多技术可以用于访问关系数据库，它们大致上可以分为两类：使用关系 概念且基于s q l 的技术，以及基于o r 映射的技术。j d b c 是访问关系数据库 的标准a p i ，不过j d b c 只是一个低级的调用级接口，直接使用它非常繁琐。 i b a t i s 等映射工具对j d b c 进行了封装，它们在一定程度上隐藏了j d b c 的使 用细节，同时保留了s q l 的全部能力。但是有时候这些工具仍显低级：我们仍 然需要维护遍布于代码或x m l 文件中的s q l 语句。o r 映射工具( 例如h i b e r n a t e 和某些j d o 实现) 为我们提供了透明持久化能力，使用这类工具，我们可以专 注于业务逻辑而忘掉自己正在使用j d b c 甚至r d b m s 这一事实。o r 映射工具 的缺点是它们过于复杂并且难以掌握。 对于需要快速开发的应用来说，我们急需一种简洁的解决方案，它应该足够 灵活同时容易使用。本文记录了一个持久层设计模式r e f l e c t i v ed a o ，这是广泛 使用的j 2 e e 核心模式d a t aa c c e s so b j e c t 的一个特例。应用r e f l e c t i v ed a o 模式， 定制可重用和易于维护的持久层方案相当容易。在r e f l e c t i v ed a o 模式的基础之 上，本文进一步设计和实现了一个轻量级j a v a 持久层框架，并将其命名为r e f l d a o 。 同现有持久层技术相比，r e f l d a o 框架有其自身的特点。由于完全构建在标准的 j a v as e 类库( j d b ca p i 和r e f l e c t i o na p i 等) 之上，r e f l d a o 没有任何多余的依 赖。r e f l e c t i v ed a o 是支撑r e f l d a o 的主要模式，反射的使用使得不用继承任何超 类就可以得到d a o 实例从而获得针对p o j o 的自动c i w d 能力。另外，r e f l d a o 还使用了许多j a v a5 0 新特性( 如a n n o t a t i o n 、g e n e r i c 、v a r a r g 等) 以便最大程 度地简化用户的持久化操作。 关键词：对象持久化设计模式框架反射 a b s t r a c t a tp r e s e n t ，t h er e l a t i o n a ld a t a b a s ei ss t i l lt h em o s tw i d e l yu s e dw a yt os t o r e p e r s i s t e n td a t a i nj a v a , t h e r ea l ean u m b e ro ft e c h n o l o g i e sc a l lb eu s e dt oa c c e s s r e l a t i o n a ld a t a b a s e s ，w h i c hc a l lb ed i v i d e di n t ot w om a j o rc a t e g o r i e s ：s q l b a s e d t e c h n o l o g i e st h a tw o r k sw i t hr e l a t i o n a lc o n c e p t s ；a n dt e c h n o l o g i e sb a s e d0 no r m a p p i n g a l t h o u g hj d b ci st h es t a n d a r da n dm o s tp o w e r f u la p if o ra c c e s s i n g r e l a t i o n a ld a t a b a s e s ，i ti s o n l yal o w l e v e lc a l l - l e v e li n t e r f a c et 1 1 a ti sr e l a t i v e l y c u m b e r s o m et ou s ec o r r e c t l y t o o l sl i k ei b a t i sd a t am a p p e ra l e 也i 1 1w r a p p e r s a b o v em b c t h e yh i d em a n yd e t a i l so ft h eu s eo fj d b cf o ru sw h i l er e t a i n i n gt h e f u l lp o w e ro fs q l n e v e r t h e l e s s ，t 1 1 e ya l es t i l la tt h el o w e r l e v e l ：w eh a v et om a i n t a i n s q ls t a t e m e n t sw h i c hw i d e l ys p r e a di nc o d e so rx m ld o c u m e n t s o 瓜m a p p i n g t o o l ss u c ha sh i b e r n a t ea n ds o m ej d oi m p l e m e n t a t i o n sp r o v i d eu sw i t ht r a n s p a r e n t p e r s i s t e n c e ，w ec a nc o n c e n t r a t eo no u rb u s i n e s sl o g i c sa n di g n o r et h ee x i s t e n c eo f j d b ce v e nr d b m sw h e nu s i n gs u c ht o o l s u n f o r t u n a t e l y o rm a p p i n gt o o l sa r e a l w a y st o oc o m p l e xa n dd i f f i c u l tt om a s t e r f o ra p p l i c a t i o n st 1 1 a tn e e dt ob ed e v e l o p e dr a p i d l y ，w en e e das i m p l es o l u t i o n ， w h i c hs h o u l db ef l e x i b l ea n du s e a b l e t h i sp a p e rp r e s e n t sap a t t e r nn a m e dr e f l e c t i v e d a ow h i c hi sas p e c i a lc a s eo ft h ed a t aa c c e s so b j e c tp a t t e r n b ya p p l y i n g r e f l e c t i v ed a o ，c u s t o m i z i n gr e u s a b l ea n dm a i n t a i n a b l ep e r s i s t e n c el a y e rc a nb ev e r y e a s y f u r t h e rm o r e ，t h i sp a p e rd e s i g n sa n di m p l e m e n t sal i g h t w e i g h tj a v ap e r s i s t e n c e f r a m e w o r kn a m e dr e f l d a o 1 1 1 er e f l d a of r a m e w o r ki sc o m p l e t e l yc o n s t r u c t e do nt h e j a v as es t a n d a r dl i b r a r i e s ( j d b ca p i ，r e f l e c t i o na p ia n ds oo n ) ，t h u st h e r ei sn o m o r er e l i a n c ew h e nu s i n gi t t h er e f l e c t i v ed a oi st h eu n d e r l y i n gp a t t e r no fr e f l d a o ， t h ea p p l i c a t i o no fr e f l e c t i o nm a k e si tp o s s i b l et og e td a oi n s t a n c e sa n dt h ea u t o m a t i c c r u dc a p a c i t ya g a i n s tp o j ow i t h o u ti n h e r i t i n ga n ys u p e rc l a s s i na d d i t i o n ，r e f l d a o u s e sal o to fj a v a5 0n e wf e a t u r e s ( e g ，a n n o t a t i o n ，g e n e r i c ，v a r a r g ) i no r d e rt o s i m p l i f yt h eo p e r a t i o no fd a t aa c c e s ss i g n i f i c a n t l y k e yw o r d s ： o b j e c tp e r s i s t e n c e ，d e s i g np a t t e r n s ，f r a m e w o r k ，r e f l e c t i o n 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得墨盗盘堂或其他教育机构的学位或证 书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中 作了明确的说明并表示了谢意。 学位论文作者签名：务考竞 签字日期：砌7 年舌月修日 学位论文版权使用授权书 本学位论文作者完全了解丞鲞盘堂有关保留、使用学位论文的规定。 特授权鑫盗盘堂可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校 向国家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名：弘季丸 签字日期：细7 年彳月日 翩签名蒜浮峻 一期：刁年月d 嗝 第一章绪论 1 1 研究背景 第一章绪论 许多j a v as e 应用程序和几乎所有的j a v ae e 应用程序都需要访问持久化数据 【1 】o 所谓对象持久化( o b j e c tp e r s i s t e n c e ) ，就是指把内存中的对象保存到可永 久保存的存储设备( 如磁盘) 中。j a v a 提供了直接从向流( s t r e a m ) 中读写对象 的能力，对于简单的应用来说，可以借由j a v a 的序列化( s e r i a l i z a t i o n ) 机制将对 象写入磁盘文件中从而保存对象的状态。不过更加复杂的应用程序( 例如大多数 企业应用) 一般会选择使用关系型数据库【2 1 ，因为这是使用最为广泛的保存持久 化数据的办法。 在访问关系数据库方面，j d b c 3 】【4 】是最基本也最强大的标准a p i 。通过j d b c ， j a v a 应用程序可以执行s q l 语句，对获取的数据进行处理，并将变化了的数据存 回数据库【5 1 。直接使用j d b c 有许多益处。首先，s q l 是查询和操纵关系数据的有 效语言，j d b c 保持了s q l 的全部能力，允许我们调用存储过程、执行特殊自定 义查询甚至使用专有的r d b m s 特性。其次，直接使用j d b c 会获得很好的性能， 若应用程序对性能有苛刻的要求，那么j d b c 无疑是最好的选择。最后，对于熟 悉关系数据库和s q l 语言的程序员来说，m b c 很容易学习。然而j d b c 只是一个 低级的a p i ，直接使用它会相当麻烦。下面是直接使用j - d b c 需要面对的挑战： - 资源管理使用j d b c ，我们必须自己确保资源得到了妥善的处理。最显著 的问题就是能否有效的管理数据库连接。每一个数据库连接都是紧缺的资 源，并且建立到数据库的连接需要不小的系统开销。在打开并使用完数据库 连接之后( 或者遇到异常时) 我们必须确保将其关闭，否则就有可能耗尽 r d b m s 的连接从而导致系统崩溃。 - 处理异常编写坚固的j d b c 代码的挑战之一是保证正确的异常处理。由于 大多数j d b ca p i 方法都可能抛出已检测的s q l e x c e p t i o n ，我们不仅要保证捕 捉这个异常，而且还要保证万一异常抛出时执行了相应的清除工作。而这些 异常处理逻辑往往非常相似，这就导致代码中出现了重复代码( d u p l i c a t e d c o d e ) 臭味【6 】。 - 难以维护我们希望软件能够容易被修改，当需要修改时最好能够跳到系统 的某一点，只在该处做出修改。但是直接使用j d b c 意味着我们需要在代码 中构造s q l 语句，一旦关系模型发生了变化，那么必须手工修改散布四处的 第一章绪论 s q l 语句以及代码。这便是发散式变化( d i v e r g e n tc h a n g e ) 和霰弹式修改 ( s h o t g u ns u r g e r y ) 臭味【6 】，它们的出现增加了软件维护的难度。 难于测试直接使用j d b c 往往导致了应用与数据源之间的高度耦合，而高 耦合、高重复是使得程序难以测试的两个主要原斟7 】。j d b c 框架非常复杂和 难于测试，这些复杂性为软件开发制造了很多困难。 由于直接使用j d b c 存在以上诸多弊端，有许多商业和开源的工具在j d b c 之 上提供了一层抽象，从而试图解决这些问题。s p r i n gj d b cs u p p o r t l 8 1 9 和i i b a t i s d a t am a p p e r ( 1 0 】【l l 】就是这样的例子。这类工具通常只是建立在j d b c 之上的一层很 薄的封装，它们本质上仍然是使用关系概念且基于s q l 的数据存取技术。这些工 具为用户隐藏了使用j d b c 的大部分细节，同时保留了s q l 的全部能力，相对于 直接使用j d b c 而言，使用这些工具可以节省大量的时间。这类工具的问题在于， 有时候它们仍然很难使用。例如使用s p r i n gj d b cs u p p o r t 时，仍然需要将s q l 语 句硬编码至u j a v a 程序中，而且需要实现各种各样的回调函数以便从结果集中取出 对象或是为准备语句设置绑定参数。 i b a t i s 的风格和s p r i n g 正好相反，它的创意非常简单：s q l 语句在x m l 文件中定义，并预留参数占位符( 可以指定参数的s q l 类型和其他细节) 。在 执行时，占位符被指定的参数值所取代，参数可以来自参数映射表、j a v a b e a n 属性或者是简单的值对象。在执行s q l 查询时，结果字段将被自动映射到对象， 映射方式与参数映射是一样的。将s q l 语句写在x m l 中是一种很大的进步，但 是当数据库方案发生变化时我们仍然需要修改x m l 映射文件，而大部分时候这 些s q l 语句可以由工具自动生成。 面向对象技术支持从类( 实现了数据和行为) 的角度创建应用程序；关系技 术支持在表中存储数据，以及通过s q l 语言操纵数据。对象技术和关系技术都已 经非常成熟，两者都各自发展了几十年，而且它们一同被用于构建复杂的软件系 统。然而这两项技术之间的配合并不是非常完美，它们之问存在的差异被叫做对 象关系阻抗不匹配( o b j e c t r e l a t i o n a li m p e d a n c em i s m a t c h ) 【1 2 】【1 3 】。对象关系映 射( o b j e c t r e l a t i o n a lm a p p i n g ) 就是要尝试将j a v a 聂j 象的状态映射到关系数据库 中的数据上，以提供透明持久性。 对j d b c 更高级的封装便是基于o r 映射理论，已经有许多非常灵活的o r 映 射产品可供选掣1 4 1 ，例如开源的h i b e n l a t e 【1 5 】【1 6 】【1 7 和a p a c h eo j b 18 1 。这类工具试 图向用户隐藏他们正在使用r d b m s 这一事实，从而提供透明的持久化能力。使 用o r 映射工具( 例如h i b e r n a t e ) ，用户通常只需要在x m l 文件中定义对象与关 系数据库之间的映射信息，然后便可以在内存中操纵对象图，其余的事情全部由 o r 映射工具来处理。 2 第一章绪论 o 瓜映射消除了开发人员编写低级数据访问代码的需要，使他们可以专心处 理业务逻辑，这极大的提高了工作效率，同时也保证了更好的可移植性。o r 映 射带来的另一个好处是透明持久化：用户可以用j a v a 的观点操纵内存中的对象 图而不必关心r d b m s 的存在。但是o r 映射工具降低总复杂性的程度可能并 没有期望的那么大，有可能只是转移了复杂性，例如得到复杂的映射文件。另外， 透明持久数据访问的代价是对这种访问的控制力度的变弱。 o r 映射工具还有一个缺点就是它们通常很复杂而且体积庞大。例如 h i b e r n a t e3 2 2 核心j a r 的大小约为2 1 3 m b ，不仅如此，要想使用h i b e r n a t e 的 全部功能还需要许多额外的依赖，如c g l i b 、l 0 9 4 j 、o s c a c h e 等等，我们必须把这 些j a r 统统放到自己的类路径下。对于w e b 应用程序来说，这通常不是什么问 题，但是对于简单的独立应用程序来说它们太庞大了。复杂通常意味着不容易使 用，实际上要想完全掌握h i b e r n a t e 并发挥它的优势绝非易事。 j d b c 功能强大却难于使用；i b a t i s 这样的映射工具极大地简化了j d b c 的 使用，但是有些时候它们仍然很低级；o r 映射工具可以让我们彻底摆脱j d b c 从而专心于业务逻辑的处理，然而它们却十分复杂且很难掌握。对于需要快速开 发的应用程序( 例如原型系统) 来说，我们需要一种简单的持久层方案，它易于 使用，只有很少或者没有依赖，同时功能强大。 本文详细描述了r e f l e c t i v ed a o 模式，使用这个模式，实现定制的持久层方 案非常容易。在r e f l e c t i v ed a o 模式的基础之上，本文迸一步设计并实现了一个 轻量级j a v a 持久层框架r e f l d a o ，它的目标是为应用程序提供简洁的持久化方案， 最大程度地简化用户的持久化操作。 1 2 标准的j a v a 持久化技术 到目前为止，一共有四种标准的j a v a 持久化技术：序列化、j d b c 、e j b 以 及j d o 。序列化机制能够让我们将内存中的对象图保存到磁盘文件中( 或其他地 方) ，然后再恢复它，不过序列化并不支持事务、并发等概念，因而应用范围有 限。下面简要介绍另外三种技术。 1 2 1 巾b c j d b c 是在j a v a 应用中访问r d b m s 的标准a p i ( j d b c 只是一个商标而不 是缩写词，不过通常认为j d b c 代表“j a v ad a t a b a s ec o n n e c t i v i t y ) 。j d b ca p i 是一种成熟的技术，s u n 公司从1 9 9 7 年就把j d b c 加入了j a v a 平台的1 1 版之 中，将其作为r d b m s 资源管理和数据访问的标准低级抽象层。最初发布的j d b c 第一章绪论 着重提供一个对关系数据库的基本调用级接口，不过从最初发布到现在，j d b c 已经经历了几次修改，每一次都增加了许多新的特性。目前，j d b c 的最新版本 是随j a v as e1 6 发布的j d b c4 0 。 1 2 2e j b e j b ( e n t e r p r i s ej a v a b e a n s ) 是用于开发和部署基于组件的企业级应用的构件 体系结构【1 9 1 。使用e j b ，开发者能够轻松构建企业级、分布式组件应用。与此同 时，在不用自身开发复杂分布式组件的前提下，开发者能够开发伸缩性好、运行 可靠及安全的应用系统。e j b 为服务器端开发引入了快速开发( r a p i da p p l i c a t i o n d e v e l o p m e n t ，r a d ) 模型。因此，在应用服务器提供商提供的分布式基础框架 ( 比如j a v ae e 应用服务器) 基础之上，开发者能够快速、轻松地构建服务器端 组件。另外，e j b 的设计初衷是为了保证e j b 应用能够在任一提供商提供的企业 中间件服务器上运行，以此获得良好的便携性与可重用性【2 。 e j b 技术实际上包括e j b 组件和e j b 容器两部分，其中e j b 容器负责管理 e j b 组件，其主要的职责是为e j b 组件提供安全、事务性、分布式的环境。e j b 组件可以分为三种类型：会话b e a n 、实体b e a n 和消息驱动b e a n 。会话b e a n ( s e s s i o nb e a n ) 用于建模业务流程；实体b e a n ( e n t i t yb e a n ) 用于建模业务数 据；消息驱动b e a n ( m e s s a g e d r i v e nb e a n ) 类似于会话b e a n ，它们的区别在于， 客户仅仅是隐式地发送消息而间接调用消息驱动b e a n ，即消息驱动b e a n 不存在 直接客户。 e j b 适用于构建大型的分布式应用，对于其他应用来说，它太复杂、太难以 使用了，另外，其可移植性也没有当初承诺的那么好。正因为如此，对于e j b 的 批评从来就屡见不鲜，而其复杂性也导致了s p r i n g 等轻量级框架的流行。e j b 的 这种复杂性还是反模式( a n t i p a t t e r n ) 滋生的好地方【2 1 1 。虽然有许多“最佳实践 和“e j b 设计模式”来指导e j b 的使用，然而具有讽刺意味的是，这些最佳实践 和所谓的设计模式往往只不过是对框架中存在的问题的简单修补罢了。 从最初发布到现在，e j b 规范经历了多次修改，每一次修改都使得e j b 朝着 简单和易用近一步迈进。最近发布的e j b3 0 规范对e j b 编程模型作了很大的调 整( 包括消除了h o m e 和组件接口、使用a n n o t a t i o n 元数据以及简化对e j b 环境 的访问等等) ，极大的简化了e j b 组件的开发过程。不过e j b3 0 变化的只是开 发和部署模型，它的核心框架和架构原理并没有改变。 4 第一章绪论 1 2 3j d o j d o ( j a v ad a t ao b j e c t s ) 是j a v a 持久化技术的一个重要创新，j d o1 0 规范 于2 0 0 2 年3 月发布，j d o2 0 规范于2 0 0 6 年2 月发布。j d o 有两个主要的目标： 第一，为程序员提供一个持久数据的透明的、以j a v a 为中心的视图；第二，让应 用程序切换数据源实现成为可胄皂【引。 使用j d o ，程序员不需要学习s q l 语言，也无需使用j d b c 来琐碎地在j a v a 对 象与结果集之间交换数据，而是可以以熟悉的、自然的方式使用j a v a 类、字段以 及引用，甚至连查询也可以用j a v a 的叙述方式( j d o q l ) 而不是s q l 来编写【2 引。 j d o 实现产品通过字节码增强来为普通j a v a 对象提供透明持久化，除此之外，使 用j d o 编写出的程序还具有跨越不同数据存储空间以实现二进制兼容性的优点： j d o 实际上被设计为可以操纵任何数据源( 只要提供相应的j d o 实现) ，从面向 对象关系数据库直到平面文件。 1 3 本论文的工作和结构安排 1 3 1 本文工作 本文详细描述了r e f l e c t i v ed a o 模式，这是广为使用的j 2 e e 核心模式d a t a a c c e s so b j e c t 的特例，它来源于作者在实际项目中的j d b c 使用经验。在 r e f l e c t i v ed a o 模式的基础之上，本文设计并实现了一个轻量级j a v a 持久层框架 n d a 0 ，其目标是为应用程序提供简洁的持久化方案，以便使快速构建应用 成为可能。下面是r e f l d a o 框架的主要优点： - 轻巧轻巧是r e f l d a o 框架的一个特点。r e f l d a o 完全构建在标准的j a v as e 类 库之上，因而没有任何多余的依赖。使用r e f l d a o ，只需将单独的r e f l d a o j a r 拷贝到应用程序类路径下即可。 - 简单简洁易用是r e f l d a o 框架的最大目标。r e f l d a o 经过了精心地设计，核 心r e f l d a o 仅包括很少的类和接口，几乎不需要任何学习便可以轻松地使用 r e f l d a o 提供的大多数功能。j a v a s e 5 0 于2 0 0 4 年9 月发布，该版本在j a v a 语法上作了很大的改进，使得j a v a 在功能强大的同时更加容易使用。r e f l d a o 利用j a v a 5 0 新特性极大地简化了用户的操作，例如，a n n o t a t i o n 的使用免去 了编写x m l 映射文件的麻烦，g e n e r i c 使得类型转换不再必要，而v a r a r g 使得批量更新更加容易。 - 灵活r e f l d a o 称不上功能完备却也十分灵活。除了最基本的c r u d 以外， 第一章绪论 r e f l d a o 还提供了分页查询，批量更新等功能以及对数据库事务的支持。通常 r e f l d a o 会自动生成必要的s q l 语句并将它们发送给r d b m s ，若需要直接通 过s q l 和r d b m s 交互，r e f l d a o 也为此留出了接i z l 。 1 3 2 全文安排 本文安排如下： 第一章绪论，本章首先讨论了流行的j a v a 持久化技术以及它们各自的优缺 点，然后介绍了三种标准的j a v a 数据存取技术，最后给出了本论文所作的工 作和结构安排。 第二章持久层设计模式，简要回顾了设计模式的历史，深入讨论了一些最 为常用的持久层设计模式以及它们的适用场合。 第三章r e f l e c t i v ed a o 模式，这一章采用一种模式模版描述了r e f l e c t i v e d a o 模式。 第四章r e f l d a o 框架的设计与实现，这一章详细描述了r e f l d a o 框架的设计 和实现。 第五章总结与展望，对本论文研究做出的总结与对未来工作的展望。 附录代码示例，一个展示如何使用r e f l d a o 框架的简单例子。 6 第二章持久层设计模式 2 1 设计模式简介 2 1 1 模式的历史 第二章持久层设计模式 设计模式这一概念最早来源于建筑学。2 0 世纪7 0 年代，建筑学家c h r i s t o p h e r a l e x a n d e r 完成了多部专著，其中记录了土木工程学和建筑学中的一些模式。随 后，软件开发社区中的一些模式先驱们从他的作品中汲取了灵感，将模式的观念 引入到了软件开发之中【2 4 】【2 5 1 。 软件开发中的模式观念通过e r i c hg a m m a 、r i c h a r dh e l m 、r a l p hj o h n s o n 和 j o h nv l i s s i d e s 四位作者( 也被称为g a n go f f o u r 或g o f ) 的经典著作【2 6 j 得到了普及。 g o f 在他们的大作中共记录了2 3 种最为常用的设计模式，这些模式后来也被人 们称为g o f 模式。当然，他们书中描述的模式并不是他们自己发明的。相反，只 是在发现类似的设计方案在很多项目中反复出现之后，他们才总结出这些模式， 并把它们记录在书中。在g o f 的著作出版之后，大量类似的软件模式论著相继问 世，它们涉及了多种不同领域和用途。 2 1 2 模式的定义 很难给模式下一个统一的定义，a l e x a n d e r 给出的定义是： “每一个模式描 述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你 就能一次又一次地使用该方案而不必做重复劳动”。尽管a l e x a n d e r 所谈论的是 建筑模式，但其定义也能很好的适用于软件设计。 一般而言，一个模式有四个基本要素【2 6 1 。“模式名称”是一个助记名，它用 一两个词汇来描述模式试图解决的问题、解决方案和效果。“问题”描述了模式 的适用场景，解释了设计问题和问题存在的前因后果。“解决方案”描述了设计 的组成部分，它们之间的相互关系及各自的职责和协作方式。“效果”描述了模 式应用的效果及使用模式应权衡的问题。 2 1 3 模式的作用 每一个设计模式系统的命名、解释和评价了面向对象系统中一个重要的和重 复出现的设计【2 6 】，使用模式我们会受益匪浅。首先，模式让我们可以复用成功的 7 第二章持久层设计模式 设计和体系结构。模式提供的解决方案已经在不同的时间、不同的项目中被反复 的用于解决类似的问题，这些使用经验使得模式构成了一种强大的重用机制，能 够让设计师避免重复发明轮子。其次，模式提供了一套通用词汇。模式名称增加 了设计师的设计词汇，使用这些词汇，设计师们能够在较高层次上进行设计和交 流。最后，模式约束了解决方案空间。模式给问题的解决方案空间增加了约束， 或者说创造出了一种边界，设计和实现都必须在这个边界内部完成，否则，就会 破坏对模式和设计的遵从，从而导致出现未经意料的“反模式”。 2 2 持久层模式概览 将持久化逻辑封装到一个独立的层次中通常是有好处的，有许多设计模式可 以帮助我们来完成这个工作，它们各自有其适用场合。本节以及后面的几个小节 讨论了最为常用的持久层模式，这些模式大多来自于d e e p a k 等人的( ( c o r ej 2 e e p a t t e r n s ) ) 【2 7 1 、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 ) ) 2 8 】 以及c l i f t o nn o o k 的d a 协a c c e s sp a t t e m s ) ) 2 9 】，因此在后面的讨论中就不再一一 标注。 2 2 1 事务脚本 描述 直接操作关系模型通常是有害的：但是对于简单的应用来说，这样做未尝不 可：直接使用s q l 语句，并解析返回的结果集。对于以集合查询和批量更新操 作为主的应用程序来说，直接使用关系数据库非常适合，因为关系数据库可以非 常高效的处理这些操作。事务脚本( t r a n s a c t i o ns c r i p t ) 可以帮助我们将业务逻 辑组织成单个过程，并将数据库调用封装在过程之中。 - 使用时机 对于只有少量逻辑的应用程序来说，使用事务脚本非常自然，容易理解而且 能获得很好的性能。但是，随着业务逻辑复杂性的增加，使用事务脚本的难度也 相应增加( 例如很难避免事务之间的冗余代码) 。事务脚本适用于业务逻辑比较 简单的应用，更复杂的业务领域需要建立领域模型。 2 2 2 领域模型 - 描述 事务脚本只是将数据存取逻辑收集起来，我们仍然按照关系模型的观点来处 第二章持久层设计模式 理问题，而没有利用面向对象技术的其他优势。对于业务逻辑比较复杂的应用来 说，抽象出领域模型( d o m a i nm o d e l ) 可以极大的化简这种复杂性。所谓领域模 型，就是合并了行为和数据的领域对象模型。使用领域模型，我们将为应用程序 建立一个完整的由对象组成的层，来对目标业务领域建模，其中有的对象建模业 务活动中的数据，有的对象捕捉业务使用的规则。 有两种风格的领域模型。简单领域模型看起来与数据库设计很类似，在这种 设计中几乎每个数据库表都与一个领域对象对应。复杂领域模型则与数据库设计 有很大地不同，它使用继承、多态等面向对象概念，是一张由互联的细粒度对象 组成的复杂网络。复杂领域模型更适合于复杂的业务逻辑，但它到数据库的映射 也比较困难。简单领域模型可以使用活动记录，而复杂领域模型可能需要使用数 据映射器。 - 使用时机 是否使用领域模型取决于系统中行为的复杂程度。如果业务逻辑复杂多变， 那么就应该利用对象模型进行处理。反之，如果只有一些简单的逻辑和少量的计 算，使用事务脚本直接操纵关系数据可能是更好的选择。 2 2 3 活动记录 - 描述 活动记录( a c t i v er e c o r d ) 也叫做主动对象，是领域模型到关系数据库的简 单映射。每一个活动记录抽象数据库表或视图中的某一行，封装数据库访问，并 在数据之上增加领域逻辑。活动记录的数据结构通常与数据库中表的结构非常相 似：类的每个字段对应表的每一列。正如其名字所示，每条活动记录负责向数据 库保存数据，从数据库加载数据以及处理作用于数据之上的领域逻辑。由于活动 记录和数据库之间的紧耦合，通常采用静态查找方法，但也可以把查找方法分离 为一个单独的类。 活动记录与行数据入1 ：3 ( r o wd a t ag a t e w a y ) 非常类似。二者的主要差别在 于行数据入口仅有数据库访问而活动记录既有数据存取逻辑又有领域逻辑。 - 使用时机 活动记录适用于不太复杂的领域逻辑，其主要优点是简单：创建活动记录很 容易，而且也很好理解。它的主要问题在于，仅当活动记录对象和数据库表直接 对应时，活动记录才比较有效。复杂的业务逻辑会用到关联、继承、集合等面向 对象概念，它们都难以映射到活动记录。不用活动记录的另一个原因是它要求对 象的设计和数据库的设计紧耦合，这使得项目的进一步重构很困难。 9 第二章持久层设计模式 2 2 4 数据映射器 - 描述、 对于业务逻辑不是十分复杂的领域模型，可以将数据存取逻辑放在领域对象 中，让它们成为活动记录。但是当业务逻辑比较复杂时，这种方案就不再可行： 复杂的领域模型往往使用继承等面向对象中独有的概念，而将它们映射至主动对 象非常困难。这时最好是引入一个中间层，让它来处理这些映射问题，从而使得 领域模型与关系数据模型可以各自独立的变化。数据映射器( d a t am a p p e r ) 就 是在保持对象和数据库( 以及映射器本身) 彼此独立的情况下在二者之间移动数 据的一个映射层。 使用时机 使用数据映射器的主要时机是数据库方案和对象模型需要彼此独立演变的 时候。数据映射器使得无论在设计阶段、开发阶段，还是测试阶段，在领域模型 上操作时都可以不考虑数据库。领域对象对数据库的结构一无所知，因为所有这 些对应关系都是由数据映射器完成。数据映射器的代价是引入了新的层次，而且 复杂的映射器难以实现。实际上，我们完全没有必要实现自己的映射器，有许多 现成的o r 映射工具可以帮助我们达到这个目的。 2 2 5 数据访问对象 - 描述 数据访问对象( d a t aa c c e s so b j e c t ，d a o ) 是一个较高层次的模式，它通过 提炼、封装对持久化存储介质的访问，提供数据的透明持久性，同时使得替换存 储介质变得十分容易。d a o 是g o f 策略模式的一个特例，同时也是一种表数据 入口( t a b ad a t ag a t e w a y ) ，可以单独实现d a o 模式，也可以将其构建在其他 模式( 如数据映射器) 之上。d a o 将数据访问逻辑封装在一个单独的层中，不 论使用哪种数据源，它总是向使用者提供统一的a p i ，这使得切换数据源相当容 易。借助d a o 对数据源的封装，客户端可以透明的访问各种持久化存储介质而 不必了解存储介质的位置和实现。 - 使用时机 d a o 使得切换数据源变得十分容易，因此若应用程序的持久化存储机制可 能发生变化，则可以使用d a o 来抽象数据访问逻辑。即使改变数据源的机会非 常小，将业务逻辑与数据存取逻辑分开也是有好处的。当业务逻辑没有复杂到需 要一个数据映射器的地步，又不想将数据存取逻辑直接放进领域对象时，d a o 提供的统一a p i 也可以使我们获益。d a o 的缺点是增加了一个层次，并且增加 1 0 第二章持久层设计模式 了面向对象设计的复杂度。 2 3o r 映射 o r 映射的目的是要克服对象关系阻抗不匹配，o r 映射主要指两个方面： 将对象映射至数据库的表，以及将对象之间的联系映射成数据库表之间的关系。 2 3 1 映射继承层次结构 图2 1 一个简单的类继承层次 有三种主要的方式可以将继承层次结构映射至关系数据库表【2 8 】，它们各有利 弊。在下面的讨论中，我们假设要将图2 - 1 所示的继承层次结构映射至关系数据 库表。这个继承体系中一共有四个类，其中p e r s o n 是抽象类，而其余三个都是具 体类。 - 单表继承 图2 2 单表继承 单表继承( s i n g l et a b l ei n h e r i t a n c e ) 将类继承层次表示为单一的一张表。如 图2 2 所示，类继承层次中的每个类的属性都被存储在p e r s o n 表中，另外添加了 额外的一列来标识从一给定行实例化出来的对象类型。单表继承比较简单( 只需 第二章持久层设计模式 要一张表) ，易于增加新的类( 仅需为新加的属性增加新列) ，并且访问速度快 ( 无需表连接操作) 。但是由于所有类直接耦合相同的表，增加了类层次体系内 的耦合，而且可能会造成数据库内空间的浪费。单表继承适合于简单或浅的类层 次体系。 - 具体表继承 如图2 3 所示，具体表继承( c o n c r e t et a b l ei n h e r i t a n c e ) 为每个具体的类创 建一张表，每个表包含该类自己的属性以及它从父类继承而来的属性。具体表继 承是最自然的一种映射方式，但是当我们修改一个类时，需要修改这个类的表以 及任何它的子类的表，这增加了维护的难度。当极少改变类型或极少出现类型间 的重叠时，使用具体表继承比较合适。 图2 - 3 具体表继承 - 类表继承 如图2 _ 4 所示，类表继承( c l a s st a b l ei n h e r i t a n c e ) 为每个类创建一张表。采 用这种映射方式时，一个类的数据有可能会被分开放在几个不同的表中。例如 c u s t o m e r 类的数据就存放在两个表中：c u s t o m e r 和p e r s o n 。因此，要获取 c u s t o m e r ，需要连接这两个表( 或执行两次单独的读取，即每个表对应一次) 。 类表继承的优点是容易理解，能够很好的支持多态，而且易于修改超类和添加新 的子类( 只需要修改添加一个表) 。其缺点是会在数据库中产生过多的表，而 且读写数据的时间可能会更长( 需要使用连接来访问多个表) 。当类型经常出现 变化或类型之间经常重叠时可以考虑使用类表继承。 | ； p e r s o n ll “ c ；u s t o m e r 1i 。 e ；m p l o y e e il “ e ；x e c u t i v e d ddd i ill iil ill il i 竺竺i1 2 1 1 堡竺! ! ! il 型型ii 生竺竺i 图2 - 4 类表继承 2 3 2 映射对象之间的关系 在j a v a 中，对象之间的关系通过引用来建立。而在关系数据库中，表之问的 1 2 第二章持久层设计模式 关系通过外键来维护。在进行o r 映射时，需要考虑两种对象关系的分类。第 一种分类基于多重性( m u l t i p l i c i t y ) ，包括三种类型：一对一关系、一对多关系 和多对多关系。第二种分类基于方向性( d i r e c t i o n a l i t y ) ，包含两种类型：单向 关系和双向关系。j a v a 中的引用是单向的，而关系技术却不支持单向关系关 系数据库中所有关联实际上都是双向的。 一 映射一对一关系 就一对一关系而言，外键可以由其中任何一个表来实现。假设用户和地址之 间存在一对一关系，如图2 5 所示为将外键放在u s e r s 表中时的情况。我们能够 很容易的通过在a d d r e s s e s 表中实现一个u s e ri d 来表达同样的关系。 图