（计算机应用技术专业论文）从dao模式到ejb3关于持久化机制的移植策略研究.pdf

ab st t a c t _一- abs tract as far ast hereare m any d e s ig n p a t t e m s o n p e r s i s t e nce b re ako uth e reand t h e re to d ay， iti sc e rtai n l yan i m p ro vem e ni fo rapp l i c at i o nd e v e l o p m e ni .u nde rth at c i rc um s t a n c e ， l o t s o f d i s c uss i o n ， suc h ashowtoc o n s i d e r abo utt h e p o p u l 丽tyo f n e w p e r s i s te nce mod e l o r t h e d e c l i n i llg o f o ld p e r s i s te nce m o d e l ， h o wtoc hoo s e the m o st e ffec t i v e d e s i gnp atte mo f d a t a per s i s te n c e ， h o wt o p ur s uefo r i nno v at i vei mpro v i n g o n th e c u rr e n t b a s e w h i c hh asb e e n i m p l e m e ni e d and d e p l o yed fo r y e ar s ， a lw a y s are t h e k e y p o i nt s o f v i e ww h 1 c hl i s t e dinarti c l e s a n dt h e m e s ， s howedi nc o l u mns and b l o g s . res e arch i ng a n dd i s c u s s i n g o n d ata p e r s i s t e nce b o o m i n g ， th ati s b e c aus e the p ro b 1 e mt od e s i gn o fd ata per s i s t i n gl ay i ss oc o m p l e xth att h e re i sn oe nd at c o n s i s t e nce o f t hes e d e b at e s ， the area t o whi c h t h e q u e s t i o n o n p e r s i s te nce r e l ate i s s o e x te n s i ve that d i ffere n ti s s u e sh a v enot b e e ns o l v e di nt 11 es am ew ay. h o w e v e 几 c o nce mi n go ndes i g no fp e r s i s t e n c ei st h ek e yto m e as u r eh o w e ffect i ve an app l i c at i o n d e v e l o p m e nti s ， e s pec i a l l y 1 a r g e r d at a p roce s s i n g p roje c t i n s hort ， t hed i s c u s s i o n o n p e r s i s t e nce i s a w a y tomak e 即p l i c at i o n d e v e l o p meni m o ree ffec t i ve， th ati s th e veryp u rp o s e o f the poi nio f th i s th e me w h i c h as s ume t he pos s i b i i i tyo f m i g r a t i n g fromd a 0m o del t o e j b 3 俪thm a n y argu ment s p ro v e d ml g r a t i o n fromd a 0toejb 3 ， t h e i d e a c o mes fromanabst r a c t v i e wo f ane x pert ， d e b u p a n d a ， w h 0 h a s b e e n workingo n the area o f d eve l opmenio f e j bc o ntai ner fo r m a n yy e ars lnth i s th e s i s ， therew i l l be l ot s o f d i sc uss i o n o n ana l y z i n g abo utthe b ack g r o u n dands i gni fi c anc eo f this re s e arch ， 山 em a i nmeani ng o f t heme w i l l be d e sc ri b edstep by s t e p among t h r e e se c t i o ns， 1 e . the ejbc o redefi n i t i o n whic h i s t h e found at i o n ， the defe c tso f d a 0m o del w h ic hi sth ep re c o ndi t i o nandt he e j b 3 pers i s t e ncear c h i t e c 1 u r ew h i c hi s t h e d i re c ti o no f m i g r a t i o nt h e natt h e m e anti me， t h e rei s a l s o t o try top r o vet h e pos s i b i l it i e s 0 f v i e wo f poi ni ， and brin g o u t a c o ncrete strat e gywhi c h m a k e s th e m i g r a t i onfromd a 0toe j bc o me t ru ethe anal y s i s o n the s t r a t e g y and i t s i m p l e m e n t a t i o n p r o c e d ure w i l l bee x p l ai n edatt hee ndo f t h i s th e s i s . k 即 w o 川 5 : d a o ， e j b ， e j b 3 ， d at a 伴 r s i st e nc e ， d e s i 即 o f p e r s i s te n c el ar， m l g r a t l o n strat e g y 学 位 论 文 独 创 性 声 明 学位论文独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果， 也不 包含为获得 南昌大学 或其他教育 机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何 贡献均已在论文中作了明确的说明并表示谢意。 学 位 论 文 作 者 签 “ (手 写 )菌 诱签 字 日期 : 制 2 年 月 外 学位论文版权使用授权书 本学位论文作者完个了 解南昌大学有关保留、 使用学位论文的规定， 有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅 和借阅。 本 人授权南昌大学可以 将学位论文的全部或部分内 容编入有关数据库 进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位沦文。 ( 保密的学位论文在解密后适用本授权书) 学 位 论文 作 者签 名 (手 写 ):截 详 签 字 琳砂 月 少 导 师 签 名 。手 写 ):释 窿 签 字 日 期 : ， 夕年若 月 /尸 日 学位论文作者毕业后去向: 工作单位: 通讯地址 : 电话: 邮编: 第 1 章 绪论 第 1 章绪论 1 . 1问题描述 一直以来，构建应用中较为困难的一步是数据持久化的实现，也就是持久 层的设计模型， 具体就jze e应用来说，目前持久层的实现还是采用d a o( d ata a cc es s o bj ec ts ) 的 方式， 这 种设 计模式最核心的思想就是帮 助开 发 人员 将j d b c 代码，也就是操作数据库逻辑代码，从业务逻辑代码中分离出来，以实现持久 层同业务层的松藕合。 本文介绍的ejb 3 持久化机制是指一种新的持久化设计模 式，这种设计模式定义了基于0 爪 映射的持久化 a p i ，开发者就可以不需要编 写大量冗余的j d b c 代码和d a o构建， 因为底层机制会实现访问数据库的工作， 开发者能够从枯燥的操作数据库劳动中解脱出来，更专注于业务的实现，这对 于所有程序员和工程师具有极大的吸引力， 促使他们使用ejb 3 的持久化机制来 代替d a o模式。 d a o模式作为一种广泛采用的持久化编程模型，随着 jze e规范的进一步 发展，在应用多年后其局限性也逐渐暴露出来，在越来越提倡快速、高效编程 的今天，传统编程模式和设计思想必然要被淘汰。目 前，业界出 现了很多诸如 ejb的 实体b e an、 hibe m a t e 、 j d o 、 top li nk等先进的 持久化设 计模型， 因 此， 近年来一直有新模式替换旧模式的趋势。 经过ejb z 沉的毁誉参半， 2 0 05年ejb规范的3 .0 版本的fi n alc r a fi终于在 这种趋势下制定完成，ejb 3的推出促进了持久化模式的繁荣，并直接导致了 e jb3 同h ib e m ate3 两大持久化标准竞争的局面。 将持久化模式从d a o移植到ejb 3的观点，正是在这种情况下提出来的， 该观点最早来自d ebu p anda的一篇文章。d ebu p anda，就任于o racle应用服务 器开发部门 ( p p l i c at i on s e rv e r d e v e l o p m e nt )的产品主管 ( p ri n c i p al拼 o d uc t m a n a g e r ) ， 致力于ejb 容器和事务管 理器的 研发， 在多 种专业杂 志发表论 文。 本文继承了d ebup anda的观点，深入分析该观点的可行性，并进一步提出 在实际编程过程中可实现的移植步骤。 第 1 章 绪论 1 . 2研究背景 1 . 2 . 1主流持久层框架纵览 目 前众多厂商和开源社区都提供了 持久层框架实现，常见的有: a p ac he o j b 、 c ay e n n e 、 j axo r 、 h i b e m ate、 i b at i s 、 j r e l a t i o n a i f r ame work、 top l i nk( o ra c l e 的商业产品) 。 a p ac he0 j b 的 优势在于对各种标准的 全 面支持 ( 不过事实上， 我们的系统 研发中并不需要同时支持这么多标准，追求多种标准的并行支持本身也成为 a p ac heojb 项目 发展的 沉重包袱) ， 且其从 属于a p ac he基金 组织， 有着 可靠的 质量保证和稳定的发展平台。 hibem at e 在2003 年末被j b oss 组织收纳， 成为从属于j b os s 组织的子项目 之一， 从而赢得了良 好的发展前景 ( 同时荣获j ol t 2 0 o 4 大奖) 。 h i bem a t e 与o j b 设计思想类似，具备相近的功能和特色，但由于其更加灵活快速的发展策略， 得到了 广大技术人员的 热 情参与， 因 此也得到了 更广 泛的 推崇。 相当a p ac heojb 迟缓的项目 开发进度表， hibem at e活跃的开发团队以及各社区对其热烈的关注 为其带来了极大的活力，并逐渐发展成j ava 持久层事实上的标准。 ib atis 相对apac he o jb和hibe rn a l e 项目 则另 具特色， ib atis 采取了 更 加开 发式的设计，通过 ibatis ，我们可以控制更多的数据库操作细节。相当而言， hibe rnat e 、 a p ac heojb 对 持久 层的 设计 则 较为 封闭 ， 封闭 化的 设 计 对持 久 层进 行了较为彻底的封装，从而将底层细节与上层架构完全分离，大多数情况下， 特别是对于新系统，新产品的研发而言，封闭化的设计带来了更高的开发效率 和更好的封装机制，但是在某些情况下，却又为一些必须的底层调整带来了阻 力，如在对遗留系统的改造和对既有数据库的复用上，表现出灵活性不足的弱 点。 此时， ib atis 就是 作为o jb和hibe m at e 的 一个有益补充而出 现的 101 气 1 . 2 . ze j b 3 的竞争对手:h i b e r n a t e hib ernat e提供了强大、高性能的对象到关系型数据库的持久化服务。利用 hibem at e ，开发人员可以按照 j ava的基础语义 ( 包括关联、继承、多态、组合 以 及j ava 的集合架构) 进行持久层开发。 hiber n a t e 提供的h q l ( hibem ate q uery 第 1 章 绪论 l an g usge) 是面向 对象的 查 询语言， 它在对象型语言 和关系型数据库之间构建了 一条快速、高效、便捷的沟通渠道。 2 0 01 年末， h i be rn a t e 第一个正式版对外发布，引来开源社区中的一片赞誉 之声。 短短几个月内， hiben l a l e 与同期的a p ac he0 jb一起迅速成为众多程序员 的热点话题。 2 0 03年6 月8 日 ， hibem atez 的发布， 为hibem ate 奠定成功的基石。 hibem at ez提供了大多数主流数据库的良 好支持， 提供了完善的数据关联、 事务 管理 、缓存 管理 、延迟加载机 制实现 。hibem ate 开始频 繁成为 t s s ( h t t p 二刀 认 几 丫 以 t h e se rv e rs i d e .c o m ) 等大型技术社区的 焦点主 题。 2 0 0 3 年末， j av a 持久层设计领域中发生了 两个里程碑事件: hib ernat e 获得了j of tz o 04 大奖以 及 hibem at e 被业内知名开源组织j b oss 收纳， 成为从属于j b oss 组织的子项目 之一。 这两个事件确立了hibem a t e 在j avao r m架构中主导地位，甚至使之成为事实 上的j ava o r m工业标准。加0 年3 月，hib ernate3 正式发布，再次将hibem at e 提升到了一个前所未有的高度，更加丰富和完善的数据库支持、实体属性的延 迟加载、对存储过程和自定义持久化实现的支持使得hibem at e 的灵活性和可拓 展性进一步增强。同时， 其性能在综合测试中业得到了令人满意的提升。 h ib e m ate 之所以如此成功，有以 下几点原因: . 快速发布、即时响应 保持活跃的开发进度以及灵活的版本更新策略。 h ib e m at e 版本更新周期甚至 以 天为计。 灵活、 快速的 更新策略时 保证软件远离b ug 的 最好办法，同时 加强 用户信心，确信hibem at e 的开发十分活跃.另外， 这样做也有一大好处，就是 可以发现哪些功能真正为用户所需。 . 避免过度设计 浪费大量的时间和精力进行软件功能的抽象和软件的灵活性扩充， 还不如多 花点时间来解决用户面临的实际问题。 . 集权 在需要由民主投票进行决策之前， 保证己 经完成了软件的基本轮廓。 软件开 发需要由一两个开明的人来领导，这样可以保证软件开发的连贯性而不至于产 生太大的分歧，同时可以 保证开发团队集中把必须实现的功能做到最好。 . 文档 如果用户不知道你的软件有这么一个功能， 就等于没有这个功能， 不如索性 将其废除，以免给源代码增加复杂度。 第 1 章 绪论 . 避免标准化 好的标准可以带来软件的互用性和可移植性， 坏的标准能够窒息软件创新。 “ 支持x x x标准” 根本就不是真实的用户需求，最好的软件是在不断地尝试， 不断地发现问题，不断的经验积累的过程中产生的。事实上的标准往往更加贴 近用户需求10 1 0 2 。 1 . 3研究内容 1 . 3 . 1选择 e j b 3 相对于e j b z .x ， ejb 3 在持久化机制上作出 革命性改进， ejb z .x本身的缺陷 不能保证移植的 进步性， 从而不在本文讨论范围内， 因 此， 从d a o向ejb的方 向移植， 只有3 .0 版本才具有进步性和可行性， 才具有研究意义。 在后面可以看 到， 本文在大多数情况下， 将ejb z ，同ejb 3 看成两种不同的产品， 在介绍ejb 技术点方面，先简单介绍ejb z 沉的概念，在重点分析ejb 3 相对ejb z .x 的改进 之处。 选择 ejb 3的另一个原因是在众多先进的持久化模式中，ejb 3是相对较新 的一个版本，因此，它的技术性更全面、更前沿，从而保证了本课题的现实意 义和研究价值。 1 . 3 . 2论题说明 本文的性质定义为理论研究，讨论的对象虽然与实际编程有关，但是并不 涉及任何具体应用实例。 一方面， 本文属于方法论， 从理论上分析d a o模式移植到ejb 3 的可行性、 实现过程、问题难点及改进方案，论题中的策略二字也强调了该论题更侧重普 遍应用实现移植所应该遵循的规则。 另一方面，也可以将本文看作是一篇ejb 3 规范的应用研究报告。一般地， 任何一种新技术、新规范问世的时候，国外都会有大量的研究报告出现，提供 对其优劣性的分析观点，本文借鉴专家们的观点，跟进最新的研究状况，将新 观点应用到实际编程中，分析可能的问题，提出解决方案。全文中也会大量出 第 1 章 绪论 现应用ejb 3 a pi编写的代码示例。 ejb 3 作为近两年广受关注 应用技术规范，从2 0 05年推出的fi n alc ra ft， 到2 0 0 6 年各产品厂商推出兼容ejb 3 的新版本产品 ( 目 前市场上真正针对ejb 3 应用的产品极少) ，国外一直都有技术专家发表最新的研究报告。较遗憾的是， 出于整理材料的考虑， 本文论据只更新到2 0 07年1 月的ejb 3 规范研究信息。 第2 童 论题分析 第2 章论题分析 2 . 1全文主旨 论文继承d ebu p anda的关于持久化设计模式从d a o移植到e j b 3 的观点， 在抽象观点的基础上，提出d ebup anda没有给出的具体实现步骤，从而使这一 观点更具说服力，因此，弥补单纯观点之外所缺少的实现过程，也是后文将一 直追求的创新方向。在详细分析移植实现策略和步骤章节，既给出理论上操作 的规则和方向，又给出部分具有代表性的示例代码说明移植理论在实际编码中 的具体体现.同时本文又恰好地说明ejb 3 规范同当前应用的可结合性， 有助于 找到应用 ejb 3 规范的发展方向。 2 . 2组织结构 全文共分八章。前两章简单阐述包括论题来源、研究内容和意义、研究背 景等相关问题; 第三章的基础概念介绍为后文的深入探讨提供了理论铺垫; 四 六章从移植的三个方面着手，包括论题所涉及技术的概念剖析、d a o模式的不 足方面、ejb 3规范定义的解决方法，详细论证移植策略的必要性和可行性，提 出移植方案的突破方向;第七章作为本文的核心，将描述移植具体实现过程， 弥补观点力度的缺失，同时提供的示例代码也证明移植策略应用于实践的可能; 最后一章是全文的总结， 分析了本文的不足之处以及今后改进的方向。 在附录a 中将汇总全文的技术名词的英文缩写，提供全称对照或中文解释，并标出该缩 写于文中首次出现的章节。 2 . 3研究意义 2 3 . 1 使用e j b 技术的场合 第 2章 论题分析 1) 要求提供远程服务。 通常，可以将应用功能建模成若干层，而每层都使用可重用组件进行构建， 这样一来，能够设计出优雅的、可管理的解决方案。但如果将这些组件部署在 不同的物理机器上，则这并不是最佳的部署方式，而且并不是所以场合都必须 这么做。 注意， 不要同如下场合混淆:为实现负载均衡， 将组件分布在多个 ( 物 理) 系统中。这两种场景的差别非常大，而且它们都存在各自 的优缺点.当然， 一旦需要考虑在应用中实现分布式组件，则首选ejb技术。ejb为j ava 平台提 供了构建可管理的分布式组件的编程模型。 2) 要求分布式事务. ejb标准优美地定义了事务语义， zpc协议是当今企业环境中广为实施的标 准技术， ejb架构能 够很好地支持它。尽管非标准的框架 ( 比如 spri ng 和 h ib e m ate)也支持分布式事务， 但 ejb容器所支持的事务完美程度是最好的。 毕竟 ejb服务器厂商存在的时间已经很长了，而且它们在实现分布式事务上沉 淀了丰富的经验。因此，e j b对事务的支持相当成熟。 3) 要求提供组件安全性。 e j b架构为e j b组件定义了标准的细粒度安全性模型。尽管 ejb架构未为 安全性方案 ( 比如单点登陆、生物认证) 提供支持，但它提供的用于认证的访 问控制的基础框架足以满足绝大多数的企业应用。因此，如果需要在应用组件 级实现访问控制 ( 而不是we b 层) ，则应该考虑使用ejb技术。 4) 要求持久化。 e j b 标准定义了持久化功能， 如今， 在ejb 应用中， 存在许多持久化方式， 比 如处于o p ensource 领域的框架， 事实标准的hibe mat e ;标准技术， 如j d 氏 当然，请不要忘记ejb中的持久化技术，尤其是c mp 。因此，如此多的持久化 方式，使得e j b组件技术具有一流的竞争力，毕竟它们都能够使用在ejb中。 5) 要求同 遗留 应用进行集成。 最近， 集成遗留应用成了企业应用中的最常见需求之一。而擅长集成遗留应 用的ejb架构在企业计算领域更是独占鳌头。 ejb 提供了多种优雅的集成模型。 比 如jz ee 连接器架构、 ejb叭 /e b 服务、 jms ，它们都能够集成异构平台中的遗 留 应用。当然，在开发新应用时也可以使用上述集成模型。如果应用需要同其 他应用进行集成，则应该考虑使用ejb框架。 6 ) 要求具有良好的伸缩性。 第2童 论题分析 在不用重新架构、 重新编程的前提下， 只需要简单地为ejb 应用添加更多的 硬件资源， 即可无止境的提高应用的伸缩性。 jze e 允许分别对ejb和w e b 层进 行伸缩性处理。将ejb层和认 七 b 层分别部署在不同的物理机器上，便能够有针 对性地改善系统的伸缩性。如果某企业应用的web界面较为简单，而中间层逻 辑非常复杂，则为部署了ejb应用的机器添加更多的资源便能够加速系统的运 行速度。 总之，如果应用需要使用事务、远程服务、安全性、 持久化能力、 应用集成 等其他集成架构设施，则应该考虑使用被无数企业应用检验过的 e j b框架。但 如果未正 确使用ejb ， 则 情况会变得很糟糕10l j 。 23 . 2移植的效果 1) 降低代码维护开销。 代码总是需要有人进行维护，维护是为了使己存在的应用具有更强的生命 力，这恰恰是这次移植的目标。举最简单的例子，代码量越大、编写越复杂的 应用，维护起来越困难，维护成本越高。可想而知，只要有办法减少代码量， 降低复杂度，就一定会降低维护成本，所以在需求相同的前提下，将一部分独 立性强，重用性强的代码交给容器或工具去实现，这是降低维护成本的有效途 径，而 ejb 3持久化机制正是实现了这一点。根据国外数据分析，应用从 d a o 移植到ejb 3 能够节省1 6%代码量和36% 的j ava 文件数量，虽然移植需要作额外 的工作，但是综合考量，对于日 后的代码维护是利大于弊的。 2) 应用能够在不同 数据库之间移植。 正如前面介绍的， 移植以后访问数据库的相关代码将不会出现在程序中， 也 即程序员不会在程序中硬编码诸如数据库驱动、版本、数据库类型等具体信息， 这就使得编写的代码能够在任何数据库上运行，在d a o中程序员必须这么写， 但是在ejb 3 中所有这些全部由一个x m l文件替代，每次更换数据库，只需要 更换这个配置文件即可，应用移植性被发挥到了最大。 3) 持久化代码的优化问题。 为了获得更好的使用效果，对于应用的代码，编写和优化总是同步进行的， 数据库是一种产品，那么程序员要对跟具体产品紧密联系的持久化代码进行优 化，可以说是异常艰难，而在这种移植策略下，设计者将数据持久化实现丢给 第2 章 论题分析 了容器，也就同时把持久化代码的优化工作丢给了容器制造商，容器的持久化 机制由容器持久化引擎实现，制造商必须不断改进产品的持久化引擎，以提高 其产品性能，而程序员只需要学会使用产品而无需去关心优化细节。 第3 章 基础概念解析 第3 章基础概念解析 3 . ij a v a s的新特性 javas 中加入了一种新的程序注释工具.通过这个工具你可以自定义注释标 记，通过这些自定义标记来注释字段、方法、类等等。这些注释并不会影响程 序的语义，但是可以 通过工具 ( 编译时或运行时)来解释这些标记并产生附加 的内容 ( 比如部署描述文件) ， 或者强制某些必须的运行时行为 ( 比如ejb组件 的状态特性) 。注释的解析可以 通过源文件的解析 ( 比如编译器或这ide 工具) 或者使用j avas中的a pis 反射机制。注释只能被定义在源代码层。 3 . zj z e e 概念简介 j a v a z 平台企业版( j ava z p l at fo rm e n t e 甲 ri s e e d i t i o n ， j z e e ) ，它是s ljn 公司 提出的，旨在为支持 j ava 语言服务器部署而提供平台无关的，可移植的，多用 户的，安全的和标准的企业级平台，从而也使得企业在这个平台上开发的程序 能够更好地融入到in te m et这个环境中。当然我们必须认识到jze e它是一个规 范，或是一系列规范的一个集合，而不是一个产品。因此我们在开发企业级应 用时必须要遵循这个规范，这样才能使我们的产品具有更好的通用性。 e j b仅仅是 jze e的组成部分之一。其中，jze e平台规范由 j c p( j ava com mun ityp ro ce ss ， j av a 工业标准组织) 制定。 jz e e 平台 规范的 使 命是， 提供 平台独立的、便携的、多用户的、安全的、遵循标准的企业级平台。而且，它 必须基于j ava 和在服务器端部署。 请注意， jze e只是规范， 而不是产品。 jze e规范定义了开发企业级软件产 品的规则。 jze e应用服务器供应商需要在他们的jze e兼容产品中实现jzee 规 范。 由于jze e只是规范( 即存在许多提供企业级j ava 产品的公司合作开发它) ， 因此它并没有绑定到特定供应商。跨平台部署能力也jze e具有的优秀特质，因 第3 章 基础概念解析 此，供应商便能够在遵循jze e规范的前提下相互竞争，以提供更好的jze e兼 容产品。当然，开发者也需要注意到现有的一些jze e产品不兼容问 题。其中， 有些是由于jze e规范本身没有清晰定义而造成的，有些是人为造成的。 目 前， j ava 存在3 个不同平台， jze e是其中 之一。如下将给出它们的各自 介绍。 请注意， 在概念上， 它们依次是前一个平台的超集， 比如jze e包含了j z s e 。 . j z me( j ava z p l at fo rm mi c roe d i ti o n ) ，j avaz嵌入式版本。 在j ava 使能设备上开发应用使用到jz me ， 如电话、掌上电脑、寻呼机、机 顶盒等。 考虑到这些j ava 使能设备的内 存限制和所具有的性能特性，j ava 引入 tj z me 。 . jzs e ， j avaz标准版本。 主要为开发a pp let、 j av a 桌面 应 用、 jz e e应 用、 移动 应用等场合提供 标准 核心库支持。这些核心库涉及面非常广，从 1 / 0 、图形用户界面 ( g ui)到网络 功能等。对于那些从事标准j ava 开发的开发者而言，他们仅需要掌握jzs e 。 . jze e ，jav az企业级版本。 为在jav a 中提供企业计算基础服务，引入了jze e .大体上，它将j ava 中现 有的各种技术集合在一起，以提供完整的、企业级的服务器端开发和部署支持。 ne e在j ava 中具有举足轻重的作用。 它为j ava 的服务器端开发构建了统一的平 台 112 1 。 3 . 3持久层框架概述 在 j a v a 发展的初级阶段，直接调用j d b c几乎是数据库访问的唯一手段。 随着近年来设计思想和j ava 技术本身的演化，出现了 许多j d b c的封装技术， 这些技术为我们的数据库访问层实现提供了更多的选择， 目 前主流的几套j d b c 封装框架 包括: h i b e m at e 、 apac heo 用、 i b a t i s 、 j d o以 及j z e e 框架中的c m p 等。这些框架以优良 的设计大大提高了数据库访问层的开发效率，并且通过对 数据访问中各种资源和数据的缓存调度，实现了更佳的性能。在项目 或者产品 研发中引入成熟的持久层框架实现，能够带来以下的好处: . 减少乏味的代码 持久层编码大多是些令人乏味的内容:获取数据库连接、 执行 s q l语句、 关闭数据库连接等等，持久层框架封装了数据库持久层的大多数技术细节，如 第3 章 墓础概念解析 事务管理，数据库连接管理、 s q l生成等。得益于这些成熟优秀的底层实现， 我们可以从j d b c编码中解脱， 从而将我们的精力和创造力投入真正有价值的工 作中。 . 更加面向对象的设计 目前的持久层框架，大多都已经建立在面向对象的设计思想之上。o r 材 ( 0 场 ec t r ati o na l m ap pi ng) 几 乎 是目 前主 流 持 久 层 框 架的 基 本 特性。 o r m为系 统设计提供了 更 加自 然的实 现方式。 我们可以 通过o r m将系 统的d o m ai n o bj ec t 自 动映射到各个数据库表， 从而编码中只需关心o bj ec t 的相关属性， 而无需再 纠缠于j d b cresu! t set 中毫无意味的字段型数据。 . 更好的性能 持久层框架大多提供了优秀的性能优化机制，如内置的数据库连接池支持， p re pare d s tate m en t 缓存、 数据缓存等。 这些优化机制的综合使用大大提升了 系统 性能。更重要的是，由于设计上更加全面的考量 ( 这些持久层框架往往有着超 豪华的设计团队) ，这些机制对于上层架构完全透明，我们无需关心其中复杂的 实现细节即可享用其所带来的性能提升。 . 更好的移植性 基于 j ava的跨平台特性，我们的系统可以在不同操作系统之间切换。但由 于数据库之间的差异，系统在数据库平台之间的迁移却遇到了阻力。上面提及 的这些成熟持久层框架，由于设计上的良好隔离，从而提供了对不同数据库的 良好支持，我们只需简单地修改其配置参数，即可实现底层数据库的切换 ( 前 提是系统 无需使用特定数据库的 独有 特性， 如o racle的p l /s q l ) 。 即 使我 们的 产品对于数据库之间的移植没有明确需求，快速移植也别有好处，公司产品通 常需要对外展示， 此时将产品移植到轻量级数据库 ( 如 h s q l 、m c k oi ) ，并在 市场人员的便携式电 脑上部署， 将会提供更加便捷的展示途径03 107 10 3 . 4持久层实现类型 一般来讲，持久层实现有3 种类型: 1) 混杂模式 混杂模式是持久化功能的原始实现模式。 即在业务类中混杂j d b c 访问代码， 从而提供所需的持久化功能。这种模式的优点在于开发的迅速便捷.对于原型 第 3 章 基础概念解析 系统或者小型应用而言显得别具意义。但我们也应该看到，基于这种模式开发 的系统，其维护性和扩展性较差，对象属性、数据库结构的变动都将直接导致 业务逻辑代码的修改。实际上，在这种模式中，我们并不能清晰的分辨出所谓 “ 持久层”的逻辑层次。 2) 基于d ata clas s 的持久层实现模式 在这种模式中，数据类 ( d ata clas s) 作为业务类与持久层沟通的桥梁，起 着承上启 下的 作用。 d atacl as s 实际 上 包含了d a o模式中 的d o m ai n cl as s/obj ec t 和d at a a cc es so r cl as s 。 d o m ai n clas s 作为对现实世界的抽象， 起着信息携带者 的作用。 而d at a a c c e s s o r c l ass 则通过j d b c代码将d o m a i n c l ass 与数据库表相 关联。在这种模式中，我们实现了业务逻辑与底层数据结构之间的分离。d ata clas s 作为一个相对独立的逻辑层次，较为清晰的体现了所谓持久层的概念。底 层关系数据的结构变化，可以较好地屏蔽在数据类这个层次，从而避免对上层 的业务逻辑造成影响。 实际上，目 前正在运行的很多 j ava企业应用系统中，基于这种类型的设计 占了很大比重。而这种模型的缺陷也显而易见，随着设计层次的增多，编码量 的增加相当可观。相对第一种混杂模式而言，系统结构上得到较大提升的同时， 项目设计和开发成本也相应增高。 繁杂的j d b c代码总得有人去编写， 单纯依靠 自 身力量进行设计和编码，这样的问题难以避免。 sunjze e规范制定小组以 及开源群体中的众多力量己经深刻的体会到了 这 一 点 ， 于 是 我 们 拥 有 te ni i ty b e an 、 j d o 、 h ib e rn ate、 i b at i s 、 apac h e o j b 这 些 杰出的持久层框架。而基于这些成熟可靠的第三方框架，我们得以从设计与工 作量之间的平衡难点中解脱。于是，有了下面的第三种解决方案。 3) 基于现有持久层框架的实现模式 实际上， 这种模式是第二种模式的延伸。 d at a cl as se s 所包含的d at a a cc es s or 和d o m ain clas s 数量并没有减少。 只是， 我们把其中最为繁琐的工作， 基于j d b c 的o r映射工作， 交由 第三方组件完成. d ata a cc es so r 中的繁琐编码工作因此得 到了空前简化，而与此同时，伴随持久层框架而来的辅助工具也大大减轻了 d o m ai n c l as s 的 编 码 负 担 10 7 1 1，2 。 3 . 50 r m 概述 第 3章 基础概念解析 目 前，无论是商业领域还是开源社区，都己 经为我们提供了丰富且久经考 验的持久层组件，使用这些成熟可靠的已有实现可以在很大程度上规避技术上 的风险，同时迅速提高应用系统开发的劳动产出比。同时，作为持久层组件的 集大成者， 持久层框架， 也出 现了不少极为优秀的实现版本， 其中o r m持久层 框架，则是未来的主流。 o r m可以 说是目 前比 较热点的 话题， 所谓o bj ee t 瓜l ationalm 叩 per， 从字 面上来理解，即 “ 对象一关系型数据映射组件” .( 这里请注意与建模领域中的 o bj e c t role m o d e l in g 相区 分。 另 外注 意这 里出 现的 术 语是“ 0 / r m a p 讲 r ， 而 非 最常见的“ o/r m ap pi ng” 。 相对来讲， 0 瓜m 叩 pi ng描述的 是一 种设计思想或者 实 现 机制， 在 这一 点 上， 与 上 面所 说的 “ 0 瓜” 的 含 义 实 际 上 一 致。 而 “ 。 瓜m ap p er ” 一般指根据0 瓜原理设计的持久化框架，其中包含了除0 瓜本身之外的更多内 容，如s q l自 生成，事务管理， c a c h e 管理等。 ) 首先 来看。 瓜， 这其中 包 含两 个关 键词: o bj ec t ( 对象) 和r ation al( 关 系 型数据) 。在目 前的应用系统中，大多数情况下，我们都必须同时面对对象和关 系型数据进行开发。 在业务逻辑层和表示层，我们将系统中的各参与实体进行面向对象的封装， 并籍此将现实世界中的逻辑进行高度抽象后，以 计算机语言实现。而另一方面， 在数据持久层，迫于目前数据库技术发展的现实，我们必须在现有的关系型数 据 库 模 型 上 进 行 持 久 化 实 现 103 】 109 。 3 . 6小结 本章通过基础概念的解释和介绍，目的是为后续章节的深入分析作好铺垫。 因此，本章涉及的范围很大，包括j avas、jze e 、o r m、持久化概念等，但是， 每一个点只是作了概要性质的介绍， 因为一方面这些理论是后文讨论的d a o概 念及ejb 3 概念的基础， 而另一方面本论题并不直接分析这些技术， 而更应该将 重点放在d a o和ejb 3 上面。另外，从这里可以看出持久化问题所覆盖理论的 广度和深度。 第4 章 移植的基础:ejb核心概念 第4 章移植的基础:e jb核心概念 4 . ie j b 的类型 企业b e an是服务器端组件，它能够部署在分布式、多层环境中。企业b e an 可以由 单个或多个j a v a 对象组成， 组件本身可能就是一个简单的j ava 对象。 暂 且抛开企业b e an的具体构成，ejb客户仅仅同其暴露的单一接口直接交互。其 中，暴露的接口 和企业bean本身必须遵循 ejb规范。ejb规范要求企业b e an 暴露若干所要求的方法， 而这些暴露的方法是供ejb容器统一管理它们使用的， 无论ejb组件部署在何种ejb容器中。 注意， 企业b e an客户的 类型可以 多种多 样， 如se rv let 、 j av aap pl et及 其他 e j b 。如果客户本身也是e j b组件，则将触发多个 ejb组件的调用。这在很大 程度上提供了解决问题的好办法，因为通过将待解决的复杂业务问题分解，并 借助于多个ejb组件能够很好地实现业务系统的开发。 e j b z . 1 规范定义了如下3 种e j b组件类型。 . 会话b e an 会话b e an用于建模业务过程。如增加记录、访问r d b ms 、访问遗留系统、 调用其他ejb组件等。 作为业务过程对象， 会话b e an能够实现业务逻辑、业务 规则、算法、工作流等， 而且会话b e an式可重用组件，供操作业务流程中的逻 辑使用。会话b e an 并不是持久化的，因此，会话b e an 并不会保存到持久化存 . 实体b e an 实体b e an用于建模业务数据，是用于缓存数据库信息的j ava 对象，通常情 况下，会话 b ean需要借助于实体 b e an 实现业务操作，如股票交易引擎 ( 会话 b e an) 处理股票( 实体b e an) 。 会话b e an和实体b e an的最大区别在于实体b e an 是实体 (i de nt it y ) ， 客户是可以 看得到的。因此，实体 b e an 能够独立于客户应 用的生命周期。对于实体b e an而言， 通过比 较它们各自 含有的数据便能够区分 不同的实体b e an。实体b e an是持久化数据组件。这种 ejb组件能够将数据永 第4 章 移植的基础: ejb核心概念 久性存储到持久化存储源中，如r d b ms 、遗留系统。 . 消息驱动 b e an ( md b ) md b类似于会话b e an， 因为它们都是为完成某些任务而存在的。 区别在于， 客户仅仅是隐式地发送消息而调用m d b的，即m d b不存在直接客户。 ejb z .0 规范引入了md b ，这种ejb组件不仅能够接收j ms消息，还能够接收其他消 息类型。一旦消息到来， ejb容器将调用md b实例处理它，因此，m d b和发 送消息的客户处于松祸合的状态。客户不能够借助于组件访问到m d b ，客户需 要借助于消息提供者提供的a pi发送消息， 然后接收到该消息的md b 将处理它。 4 . ze j b 的组成部分 1 )e j b服务器 给 ejb容器运行于其中提供了一个组织框架和运行时环境，它为ejb容器 的多重处理技术， 负载平衡和设备存取等问 题提供可用的系统服务， 在一个e j b 服务器中可能包含有一个或是多个ejb容器。 他使得这些ejb容器对外界可见。 e j b服务器可能也提供一些由开发商自己定义的特性， 比如是一个可选的数据存 取接口 ， 额外的c o rba服务， 安全套接字(s s l)的支持等 等。 其他对命名 服务， 交易管理的支持也是ejb服务器必须的功能。 2 )e j b容器 顾名思义ejb存放于其中，由 他负责管理这些ejb 。 ejb容器最重要的职责 是提供一个e nte甲 risob e ans 可以 运行的环境。 ejb容器装载ejb ， 并且使得客 户端程序能进行远程调用。 从本质上讲， ejb容器是客户端程序和b e ans 之间看 不见的中间人。 他们负责客户端程序连接到b e ans ， 执行事务协调，