（计算机应用技术专业论文）轻量级j2ee架构的应用.pdf

硕士学位论文 摘要 本文首先介绍了课题的背景和应用现状，指出传统的j 2 e e 架构由于种种原因 己经不能适应企业应用系统的发展要求。接下来，文章简单介绍了轻量级的j 2 e e 应用程序体系结构，着重介绍了轻量级开发相对于传统的开发方法的优势，通过 对比各体系结构，引出了本文重点研究的最新的基于s t m t s + s p 渤g + h i b e m a t e 框架 的轻量级班e 应用框架体系结构。 本文所介绍的架构方案的目标就是使得j 2 e e 体系结构朝着更简单、更理性的 方向发展，并且采用了面向方面的程序设计( a s p e c t o r i e n t e d p m 鲈a m m i n g ，a o p ) 等新近发展的技术，同时充分利用了j 2 e e 平台的多种优秀的开源框架。在表示层 采用s t 九j t s 框架，该层主要负责用户数据收集和处理结果显示，s n t s 采用m v c ( m o d e l v i e w c o m r 0 1 ) 的设计框架，具有更好的可扩展性，能够更好地实现表示与 内容之间的分离。业务逻辑层采用s p “n g 框架，该框架是一个全面的、模块化的 框架，有分层的体系结构，开发人员能够选择使用它独立的任何部分。s p r i n g 框架 有效的组织了系统中的中间层对象，消除了组件对象创建与使用耦合紧密的问题， 同时消除了使用各种各样格式的属性定制文件的需要，在整个应用实现中，可以 通过一种一致的方法进行配置。数据持久层采用h i b e m a t e 框架，h i b e r n a t e 提供了 j 2 e e 体系结构中的轻量级持久框架，提供了j a v a 对象和数据库模型的一一对应的 映射关系。同时还提供了面向对象的查询语言( h i b e m a t eq u e r y l a n g i 】a g e ，h q l ) 和恢复机制。使用埘b e r n a t e 框架，不仅可以大大减少操作数据库的工作量，更重 要的是使程序员能够使用面向对象编程思想来操作数据库。 最后，实现了一个简单的基于轻量级j 2 e e 架构的进销存系统，展示了运用此 新技术在应用实现中的高效便捷之处，从而探索出一条基于此架构开发企业级应 用系统的一般模式。 关键词：j 2 e e ；架构；p o j o ；面向方面编程；h q l ；依赖注入；m v c ； 轻量级j 2 e e 架构的应用 a b s t r a c t a tt h ef i r s tp a r to ft h ep 印e r t h ea l 】t h o ri 址r o d u c e st 1 1 eb a c k g r o u n do ft h er e s e a r c h p r o j e c t 卸di t sc u r r e n te n v i r o n m e m ，p o i n to u tt h a tt h et r a d i t r i o n a ij 2 e ea r c h i t e c t u r ei s n o ts a t i s f y i n gt h ed e v e l o p m e n to ft h ee n t e r p n s e 印p l i c a t i o ns y s t e m f o l l o w i n gt h a t ，t 1 1 e a u t h o rr e p r e s e n t st h el i g h 船e 适h tj 2 e ea p p l j c a t 主o na r c h i t e c t u f e ，a 1 1 de m p h a t j c a l l yp o i n t o u tl i g 帅v e i g h ta r c h i t e c t u r ea d v a n t a g e sc o m p a r e dw i t ht r a d i t i o n a la r c h i t e c t u r e b y c o m p a r i n ge a c ha r c b i t e c t u r e ，t h ea u t h o rl e a d st ot h em a i np o i mo ft h ep 印e r ， t h e a r 拙。咖r eb a s e d0 n s t m t s + s p r i n g + h i b e n l a t e 丘a m e w o r k i n l i g h 咐e i g h t j 2 e e 印p l i c a t i o na r c 衄e 曲】r e t h eg o a lo ft h i sa r c h “e c t u r ei st om a k et h ej 2 e e 印p l i c a t i o na r c l l i t e 咖r em o r e s i m p l ea n dm o r er a t i o n a l i n a d d i t j o n ， t h ea u t h o ri m r o d u c em en e wt e c h n 0 1 0 9 y a o p ( a s p e c t0 r i e m e dp r o 野a m m i n g ) a n ds e v e r a lo u t s 七a i l d i n go p e ns o u c e 劬m e w o r k s i i lt h e “e wt i e r t h ea u t h o rs e l e c t ss t 九l t sa si t sf h m e w o r kt h e 疔a m e w o r ki s c h a r a c t e r i z e da sam v c 矗a m e w o r k ，i tj sr e s p o n s i b i e 旬rc o l i e c t i n gt h eu s e rd a t aa n d h a n d l et h er e s u l t ，m a k et l l ed e v e l o p m e n to f w e b 印p l i c a t i o nm o r es c a l a b l e ，a n ds 印a r a t e t h ep r e s e n t a t i o na n dc o m e n tc i e a r l yi nt h e1 0 9 i c a l t ie f ，t h ea u t h o rs e l e c ts p n ga si t s 纳m e w o r k ，a sa m p r e h e n s i v ea n dm o d u l a r 行a m e w o r kw i t ht i e r e da r c h i t e c t u r e ， m a k e d “e l o p e ru s ee i t h e rp a r to ft h ef h m e w o r k s p r i n g 矗a m e w o r ke f r e c t i v e l yo 唱a n i z e dt h e m i d d l e w a r eo b j e c t ，g e tr i do ft h ep r o b l e mo ft h et i g h tc o 蚰e c t i o no fc o m p o n e m c 0 1 1 s t r u c t i o na n de m p l o y m e n ta n dt h en e e do fu s i n gv 撕o u sp r o p e 哪f i l e s i i lt h ew h o l e 印p l i c a t i o np r o j e c t s ，s p r i n g 疔a m e w o r kp r o v i d e sa nu n i f o mm e c h o dc o n f i g u r a t i o n s i n t h ed a t ap e r s i s t e n c et i e r ，t h ea u t l l o ru s e sh i b e 柏a t e 行a m e w o r kb a s e do no ，rm a p p i n g ， t h i s 厅a m e w o r kp r o v i d e sl i g h tp e r s i s t e n c e 疔a m e w o r ki n 佗e ep l a t f o r m ，t h eo n et oo n e m a p p i n gr e i a t i o na n dt 1 1 eo b j e c t - o r i e n t e dq u e r yl a n g u a g ea n dt h er e c o v e r ym e c h a n i s n f o rt h eh i b e m a t e 纳m e w o r k ，d e v e i o p e r sc a n 铲e a t l yr e d u c et h ew o r ko fo p e r a t i n g d a t a b a s ea n dm a k ed e v e l o p e r s 矗- e e l yu s et h eo b j e c t - o r i e n t e dm e t h o dt o o p e r a t e d a t a b a s e f i n a u y ，a r e rt h ed 吐a i l e da n a l y s i so ft h ec o r et e c h n i q u eo fe a c ht i e r 仔a m e w o r k ， t h ea u t h o ra p p i i e st h et e c h q u et ot h ed e v e l o p m e n to fa 正m p l ej i n x i a o c u ns y s t e n t l l r o u g ht h ed e s c r i p t i o no ft h er e q u i r e m e n to ft h es y s t e m ，s h o w st h ec o n v e n i e n c eo f s y s t e mo f d e l o p m e n ta n dm a i n t e n a n c ea n dm a k eo u tan e ，m e t h o dt ob u i l de n t e r p r i s e s v s t e m k e yw o r d s ： j 2 e e ；a r c h i t e c t u r e ；p o j o ；a o p ；h q l ；d 印e n d e n c yl n j e 吐i o n ；m v c u 硕士学位论文 插图索引 图1le n t e r d r i s ej a v a b e a n 的体系结构1 图1 2 轻量级多层j 2 e e 应用程序架构基本框图5 图2 1m v c 模块结构图9 图22s t r u t s 框架1 2 图31s p r i n g 框架1 7 图3 2 典型的s p r i n gw e b 应用1 8 图3 3 在m o v i e l i s t e r 中直接创建m o v i e f i n d e r 实例时的依赖关系1 9 图34 引入依赖注入器之后的依赖关系2 0 图4 1h i b e r n a t e 体系结构图2 5 图4 2 碰b e r n a t e 扩展体系结构l 2 6 图4 _ 3 碰b 盯n a t e 扩展体系结构2 2 6 图4 4 类继承图3 1 图4 5 数据库关系图3 2 图5l 系统结构模块图3 7 图5 2 数据表关系示例3 9 图5 | 3 类层次图4 0 图5 4 表示层页面关系示意4 1 图54 添加资料页面4 5 图5 5 商品采购信息页面4 6 图56 商品销售信息页面4 6 兰州理工大学 学位论文原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取 得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其 它个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡献的个 人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果 由本人承担。 作者签名：莒荔眵。移 日期：细，年占月5 日 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学 校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查 阅和借阅。本人授权兰州理工大学可以将本学位论文的全部或部分内容编入 有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本 学位论文。 本学位论文属于 1 、保密口，在年解密后适用本授权书。 2 、不保密团。 ( 请在以上相应方框内打“、”) 作者签名，茜钽移乒 导师签名：z 吖n 日期：仉帕年二月厂日 日期：细f 年月，日 硕士学位论文 第1 章绪论 j 2 e e 是s u n 公司推出的一个开发分布式企业应用系统的平台，其中融合了大 量的技术标准，提供了多层分布式应用模型、组件复用能力、统一的安全模型和 灵活的事务控制，为开发和配置企业应用程序提供了健壮、稳定的服务。 传统的j 2 e e 架构一般运用j s p 、j a v a 、s e r v l e t 、e j b 以及j d b c 构建企业级应 用程序满足了当前的开发需求，但是这种架构仍存在诸如可移植性差、开发周期 长、测试困难等弊端，并且重量级的基于e j b 的架构对于解决许多问题都过于复 杂。例如，实体b e a l l 会让您为每个实体编写7 个文件，同时，e j b 容器a p i 强 迫您编写一些接口或一个组件模型。面对这种情况，轻量级j 2 e e 架构技术应运而 生，轻量级架构方案在继承传统的j 2 e e 采用多层架构的基础上，主要针对业务 逻辑层和数据持久层进行了较大的改进和突破【l 】。从而探索出一条基于此架构开发 企业级应用系统的一般模式。 本文着重介绍了轻量级j 2 e e 架构各层所包含的各种应用框架删，为了展示运 用此轻量级框架构建j 2 e e 应用系统一般方法，最后实现了一个简单的进销存系统。 1 1 课题研究现状 1 1 1 传统e j b 架构 传统e j b 架构的核心部分是e j b 服务器，其它相关的主要组成元素有e j b 容 器、本地接口、远程接口等【3 1 。各个组成部分之间的关系如图1 1 所示。 髋 a 釜f h 参 r 裂 e i b 容器 啪服务器 图1 1e n t e r p r i s ej a v a b e a n 的体系结构 轻最级j 2 e e 槊构酌应用 e j b 服务器是管理e j b 容器的应用程序，提供了对可访问d i ( j a v a 命名和目 录接口1 的名称服务和事务服务的支持 4 】。e _ b 构件模型是j 2 e e 体系结构的核心部 分。j 2 e e 规范要求所有e j ba p i 及其实现都包含在j 2 e ee j b 容器中。 e j b 容器是一个管理个或多个e j b 类实例的抽象。它通过规范中定义的接 口使e j b 类访问所需的服务。 本地接口与存根( h o m e i n t e f f a c e 和s t u b ) 列出了所有定位、创建、删除e j b 类 实例的方法。h o m e 对象是本地接口的实现。e j b 类开发者必须定义h o m e 接口。 容器厂商应该提供从h o l e 接口中产生h o m e 对象实现的方法。 远程接口( r e m o t ei n t e 面c e ) 给出了e j b 类中的商业方法圈。e j b 0 b i e c t 实现 远程接口，并且客户端通过它访问e j b 实例的商业方法。e j b 类开发者定义远程 接口，容器开发商提供产生相应的e j b 0 b j e c t 的方法。客户端不能得到e j b 实例 的引用，只能得到它的e j b o b j e c t 实例的引用。当客户端调用一个方法，勘b o b i e c t 接受请求并把它传给e j b 实例，同时提供进程中必要的包装功能。客户端应用程 序通过h o m e 对象来定位、创建、删除e j b 类的实例，通过e j b 0 恸e c t 来调用实 例中的商业方法。 e j b 容器使用e n t e r p r i s eb e a l l 的客户端通过它的本地接口创建它的实例。本地 接口包含或多个用来创建e n t 唧r i s eb e a i l 实例的c r e a t e 0 方法【6 】。这个本地接口 不是由b e a n 来实现，而是通过称为h o m eo b i e c t 的类来实现。一个h o m eo b j e c t 的实例在服务器中实例化，使得客户端可以访问它们。 一个h o m eo t ! i e c t 的引用被放在名字服务中，客户端能通过j n d i 访问它。e j b 服务器一般提供某种名字空间的实现，虽然有时可以使用外部的名字空间。在这 两种情况下客户端都必须知道名字空间的位置以及卧i 的上下文类。 n l t e r 面s eb 锄开发者定义c j b c r e 砒e ( ) 方法的同时必须在h o m e 接口中声明与 其相应的c r e a t e 0 方法1 7 】o 实体b e a n 可以包含f i n d e r 方法以使客户端能定位已有的 实体b e a n 。 容器和e j bo b j e c t 对规范经常引用由容器或e j bo b i e c t 提供的服务。支持 e 唧r i s eb e 姐的e j b o b j e c t 和容器类都由容器开发商提供。这些类必须完成b e a n 容器的功能1 8 】。对b e a i l 来说容器和e j bo b j e c t 是不同的入口点，对某个特殊的服 务提供独特的支持能力。 客户端不会直接访问e n t e r p r i s e b e a i l 中的任何方法。客户端通过e j bo b i e c t 间 接调用b e a 中的方法，e j bo b i e c t 就象一个代理一样。在把调用通过e j bo b i e c t 传递时，容器开发商通过包装编码插入其自己的功能，这称为方法插入1 9 】。方法插 入的一个例子是为每个方法调用创建一个新的事务上下文，当方法返回到e j b o b i e c t 时提交或回滚事务。当容器厂商的工具在安装b 啪产生存根s n l b 和骨架 s k e l e t o n 时，它产生b e a n 的e j bo b i e c t 一个s t u b 和s k e l e t o n 。实际上它并不创建 b e a j l 本身的s 劬和s k e i e t o n ，因为b e a r i 不会通过网络被访问。e j b o b i e c t 是真正 的网络对象【l ”。b e a n 是包含应用相关的商业编码的代表。包容器也可以调用b e a n 中的某个方法。例如，容器保证当一个b e a n 实例生成后，h o m eo b i e c t 中的c r e a t c ( ) 的任何参数会传递b e a n 相应的e b c r e a t e ( ) 方法。 根据e j b 的功能角色把e 旧进行划分为会话e j b 和实体e 毋。在每一个主要 的功能角色中，又可以根据其中的子角色对e j b 进步划分，通过将e j b 划分为 不同的角色，程序设计者可以根据功能为专用的开发模型开发e j b ，同时，这些角 色的划分使得容器能够根据自己的编程模型类型决定如何对某个特定的e j b 进行 最佳管理【。 1 1 2 轻量级架构 所谓的轻量级一般是相对于e j b 的重量级面向组件模型而言的，鼓励人们使 用简单原始的j a v a 对象( p l a i no r d i n a r yj a v ao b j e c t ，p o j o ) 编程。s p r i n g 是一 个轻量级容器。s p 血g 框架就是作为代替e j b 的一种轻量级技术。e 旧技术提 供了核心的企业服务，但是e m 技术是一个复杂的、基于组件的模型编程，业务 组件被放入一个e j b 容器中，该容器提供诸如事务、远程控制、安全和持久性之 类的服务，重量级的基于e j b 的架构对于解决许多问题都过于复杂。例如，实体 b e a n 会让您为每个实体编写7 个文件。如今，许多业务仍然需要企业服务，但 它们正在寻找达到该目标的新方向。它们使用轻量级容器。实际上，最新的e j b v 3 o 标准就使用了轻量级容器模型i 】 】。 传统的大多数容器a p i ( 如e m a p i ) 强迫您编写一些接口或一个组件模型。 将您的组件放入该容器后，容器会为您处理一些事情。在基于e 旧的架构模型中， e j b 容器提供企业服务。s e l e t 容器( 例如a 口a c h ej a k a r t a t o m c a t ) 实现了s e r v l e t a p i ，使您可以将动态内容建立到服务器页面中，该页面随后会被发送到w c b 浏 览器。 相对于传统容器强迫使用指定的编程模型，轻量级容器则不是。它们使用普 通j a v a 对象。容器然后将p o j 0 绑在一起，并将服务与它们相关联。 轻量级容器的共同特征包括： ( 1 ) 基于p o j o 的编程：轻量级容器不具侵犯性，它不强迫执行任何a p i 。 ( 2 ) 生命周期管理：轻量级容器管理放入其中的对象的生命周期，最低限度 下，它们实铡化并销毁对象。 ( 3 ) 依赖性解析：轻量级容器提供了一个普通的依赖性解析策略。多数容器 现在支持称为依赖注入的策略。还有一些支持j a v a2 平台企业版( j 2 e e ) 风格的 策略，称之为服务定位。 ( 4 ) 使用拦截和a o p ，将服务与p o j o 相关联。 轻量级j 2 e e 架构的应用 轻量级容器有许多胜于其它容器架构的优点。例如，可以使用一个更加简单、 基于p o j o 的编程模型。使用p o j o 编程，应用程序会更加易于测试。同时，对 象也可以在容器外运行。例如，对象可以运行在一个普通的铡试用例中。通过依 赖注入，轻量级容器减少了组件间的依赖性。它们也保护了您在代码上花费的心 血，因为您可以在容器间移动应用程序的大部分。 相对于重量级的基于e 嵋的架构，轻量级的架构有以下优点【l j ： ( 1 ) 架构简单，但是功能强大。 ( 2 ) 可以通过配置w 曲容器集群来达到横向扩展。 ( 3 ) 相对于基于e j b 的架构，不用编写任何针对特定容器的代码，而且更容易 学习、更容易配置。 ( 4 ) 轻量级容器通过采用a o p 技术，能够提供成熟的声明式服务。 ( 5 ) 控制依赖注入可以让轻量级服务器组装对象，对象与合作者之间的依赖 关系，通过普通的j a v a b e 姐属性或是构造函数的参数来体现，而i o c ( i n v e r s j o no f c o n 仰i ) 容器负责在运行时解析这些关系。 ( 6 ) 很容易在应用服务器之外进行业务对象的单元测试，测试驱动的开发过 程就变得更加容易。 轻量级容器的缺点： ( 1 ) 相对于e j b ，目前轻量级容器还没有形成标准 ( 2 ) 与e j b 架构相比，这种技术的发展还不是很成熟 1 2 轻量级架构各层简介 1 2 1 概述 下面是采用轻量级容器的多层j 2 e e 应用程序架构基本框图： 1 2 2 表示层简介 图1 ，2 轻量级多层j 2 e e 应用程序架构基本框图 主要提供给用户一个界面，可以是本地的，也可以是远程的。表示层负责将 业务逻辑层提供的服务展示给用户。它应知道如何处理用户的请求，如何同业务 逻辑层交互，并且知道如何选择下一个视图显示给用户。该层有多个可选择的框 架，如s 讥l t s ，w 如w j r k 2 和e c h o 等。 s 虮i t s ：是本文采用和将要重点阐述的表示层框架，咖t s 是一个基于s 1 1 nj 2 e e 平台的m v c 框架，是a p a c h e 软件基金会旗下j a k a r t a 项目组的一部分l l ”。它主要 是采用s e r v l e t 和j s p 技术来实现，把s e r v l e t 、j s p 、自定义标签和信息资源整合到 一个统一的框架中，关注于c o r l 廿0 l i e r 流程，开发人员利用其进行开发时不用再自 己编码实现全套m v c 模式，极大的节省了时间“。 w 曲w o r k 2 ：j i v e 论坛采用的框架。和s 廿u t s 不同的是，w 曲w o r k 2 是更简单的 框架，每个a c t i o n 都是一个简单ja _ 豫对象( p o j o ) ，不需要a c t i o n b e a n 类。可以直 接使用模型驱动和域对象。w 曲w o 越可以使用多种视图( e w ) 技术。如j s p ， v e l o c i 钒f r e 锄列k c r 等。因为拥有功能强大的脚本语言，因此不需要s 缸i t s 那么多 标签库。另外，w 曲w o r l ( 2 还拥有一易于使用的验证框架，使用拦截器( 锄珊c e p t o r ) 实现，与a c t i o n 无关。 e c h o ：是一个面向对象的w 曲开发框架，e c h o 可以让开发者象开发a w t 、 s w i n g 应用程序一样，用面向对象的方式设计w e b 界面。e c h o 支持h t m l ，j s p 作 为模版，支持完全的组件一事件的模型，所有的c s 的交互采用帆h t 中r c q u e s t 方式。整个e c h o 的w 曲应用全部在单个的w e b 页内运行不用重复载入页面 轻量级j 2 e e 架构的应用 也不用每次刷新整个页面。用户的输入信息是通过x m l 文档经过旺h 呻r e q u e s t 传输。服务器也用包含同步指令的x m l 信息格式加以响应，进而通过可插入式的 客户端j a v a s c r i p t 模组进行处理。这样就使用户感觉到像操作桌面应用程序一样的 流畅。同传统的啪应用程序相比，性能也发生戏剧性的改善。在e c h o 中，所 有的w e b 界面的绘制功能都是e c h o 的基于j a v a 的u i 工具完成的。开发者只需 要像开发s 谢n g 界面一样，用它的u i 工具来写界面就行了。 1 2 3 业务逻辑层简介 在整个应用系统架构中，该层占有主导地位，该层把业务逻辑提供给表示层， 暴露多个服务接口来提供表示层需要的所有操作，并且在必要的时候可以通过集 群等技术提供横向的可伸缩性。业务层主要负责管理业务层的逻辑对象，包括逻 辑对象对于底层的事务管理，分布式管理，逻辑对象的生命周期管理，同时还维 护逻辑对象之间的调用关系，好的业务层框架可以使系统易于开发，测试和维护， 是表示层与数据持久层之间的重要桥梁。 传统的业务逻辑层技术有主要采用e j b 技术。另一种选择就是使用由p o j o 构成的业务逻辑层，他们运行在( 比如s p r i n g 或者p i c o c o n t a i n e r ) 中，由轻量级 的容器提供管理业务对象的生命周期、提供对象定位寻址功能、为对象提供一些 企业服务( 比如声明式的事务管理) ，比较流行的轻量级业务逻辑层框架主要有两 种： s p r i n g ：是本文采用和将要重点阐述的业务逻辑层框架，s 州地是基于i o c 概 念的框架，主要包括以下特性l l 】： ( 1 ) b e a n 管理：s p r i n g 可以有效地组织我们的中间层对象，它能够消除 由出e t o n 的缺点，并易于实现良好的面向对象编程方法，即“编程到接口”。 ( 2 ) 声踢式的事务管理：s 呻n g 利用a o p 实现事务管理，而无需借助于e j b 容器，利用这种方法，事务管理可以用于任何p o j o 中。s p 血g 的事务管理不局限 于j 1 a ，而是可以采用不同的事务策略，如编程序的事务处理和声明式的事务。 p i c o c o n t a i n e r ：同s 研n g 框架一样，p i c o c o r n a i l l e r 也是一个基于依赖注入的业 务逻辑层框架，该框架有效的管理业务逻辑对象的关系以及生命周期，使开发人 员写出高效的易于测试和维护的代码。同时，p i c o c o n t a i n e r 框架并不要求其中的 业务对象实现其a p i ，提供了框架使用的灵活性。 1 2 4 数据持久层简介 通过持久化存储来访问对象。数据持久层框架目标是为整个项目提供一个高 层、统一、安全和并发的数据持久机制。完成对各种数据进行持久化的编程工作， 并为系统业务逻辑层提供服务。数据持久层提供了数据访问方法，能够使其它程 序员避免手工编写程序访问数据持久层，使其专注于业务逻辑的开发，并且能够 在不同项目中重用映射框架，大大简化了数据增、删、改、查等功能的开发过程， 同时又不丧失多层结构的天然优势，继承延续j 2 e e 特有的可伸缩性和可扩展性。 数据持久层是介于业务逻辑层和e i s 层之间的桥梁，它封装了与e i s 层交互 的逻辑。存在多种方法可用来实现： ( 1 ) j d b c ：直接基于s q l 语句的访问r d b m s ，这是最为灵活的方法，然 而，低级的j d b c 难以使用，而且质量差的巾b c 代码很难运转良好。 ( 2 ) e 血坶b e a n s ：属于传统的j 2 e e 架构所采用的技术，c ，的勖t 时b e a l l 是一种分离数据访问代码和处理o r m 的昂贵的方法，它是以应用服务器为中心的 方法，即e m 毋b e a n 不是将应用与某种数据库类型而是e j b 容器约束在一起。 ( 3 ) 第三方的o 瓜m a p p i i l g 技术主要有：h i b e m a t e 、j d o 、t 0 p l i n k 等。 h i b e m a t e ：是本文采用和将要重点阐述的数据持久层框架，h i b e ma _ t e 是一个面 向j a v a 环境的对象关系数据库映框架，把对象模型表示的对象映像到基于s q l ， 的关系模型结构中去。它对j d b c 进行了轻量级的对象封装，使j a v a 程序员可以 随心所欲的使用对象编程思维来操纵数据库。h i b e m a t e 不仅仅管理j a v a 类到数据 库表的映射，还提供数据查询和获取数据的方法，可以大幅度减少开发时人工使 用s o i 和j d b c 处理数据的时间。h i b e m a t e 是一个开源的o r m 框架，它可以支 持所有主流s o l 数据库系统，h i b e n l a t e 的查询语言为对象和关系架起了非常好的 桥梁。 珏b e m 如提供了强大的功能以实现：数据读取和更新、事务管理、数据连 接池、查询和实体关系管理等。 j d o ：j d o 是面向大型信息系统的一个完全的j a v a 对象持久化方案，该框架完 全支持对象模型，包括引用、集合、接口、继承，通过使用字节增强码机制，完 全透明持久化，这使得业务对象完全独立于任何数据库技术。j d o 是一个通用持 久性框架，潜在地可以处理任何类型的数据源，包括r i ) b m s ，o d b m s ，t p 监控处 理，a s c i i 无格式文件，v i i 。文件，p r o p e n i e s 文件，大型机上的c o b 0 1 数据库等。 j d o 是一个标准的j a v a 持久化a p i ，但是相对于h i b e m a t e ，被公众接受的进展相 当缓慢。 另外还有一些商业的0 瓜m 印p h l g 技术，如t o p l i n k 等。 1 3 本文的组织结构 本文共分为5 章： 第l 章：绪论。主要包括轻量级j 2 e e 架构技术概述、开发方法、体系结构、 国内外现状、本论文的项目背景和组织结构。 轻量级j 2 e e 架构的应用 第2 章：表示层框架s 劬t s 。综述了m v c 组成结构、s t r i 啦体系结构和建模机 制及具体的实现细节。 第3 章：业务逻辑层框架s p 血g 。是论文所阐述架构的核心部分，系统的讲述 了业务逻辑层的体系结构以及s p 血g 的实现特定。 第4 章：数据持久层框架h i b 啪a t e 。系统的阐述了数据持久层的设计要点及 h i b e m a t e 的实现特点和实现方式。 第5 章：进销存系统设计。用轻量级的j 2 e e 体系架构实现一个进销存系统， 并阐述实现平台、实现过程及主要实现界面。 在结束语中，总结全文，并指出自己所做的工作、此种架孛句的前景以及产品 需要进一步改迸的地方。 埘j ：学位沦文 2 1 艄模式 第2 章表示层框架s t r u t s 2 1 1m 、，c 组成部分 表示层主要负责用户数据收集和处理结果显示，对于存在大量页面及多次客 户访问的w 曲交互式的应用系统，如何有效实现页面调度、如何有效实现表示与 内容的分离是关键。基于m v c ( m o d e l e w c o n 仃0 1 ) 的设计框架对于设计此类应用 系统是一个非常合适的选择，用它创建的系统更加灵活，而且具有更好的可扩展 性，能够更好地实现表示与内容之间的分离。m v c 的模块结构图如图2 1 所示。 方法调用 圄2 fm 她模块结构图 下面对m v c 模型的各部分做简单的介绍： 视图哪e w ) ：代表用户交互界面，对于w 如应用来说，可以概括为h 眦l 、 j s p 、j s f 等界面，但有可能为x h n 也，m 。和a p p l e t 等。随着应用的复杂性和 规模性。界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，m v c 设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而 不包括在视图中的业务流程的处理【1 4 l 。业务流程的处理交给模型( m o d e ) 来处理。 比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输 入数据和请求传递给控制和模型。 轻量级j 2 e e 架构的应用 模型( m o d e l ) ：就是业务流程状态的处理以及业务规则的制定。业务流程的处 理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理 结果。业务模型的设计可以说是m v c 最主要的核心。传统的e j b 就充当模型的 角色，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的 组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以 利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注 于业务模型的设计。m v c 设计模式告诉我们，把应用的模型按一定的规则抽取出 来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体 不能隔得太远，也不能太近。m v c 并没有提供模型的设计方法，雨只告诉你应该 组织管理这些模型，以便于模型的重构和提高重用性。 控制( c o n n d l l e r ) ：可以理解为从用户接收请求，将模型与视图匹配在一起， 共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一 个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。 控制层并不做任何的数据处理。例如，当用户点击一个链接，控制层接受请求后， 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合 要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应 多个模型。w 曲层应用程序的控制器完成以下任务【i 5 j ： ( 1 ) 截取客户端的h 1 f r p 请求。 ( 2 ) 每个请求翻译为要执行的具体业务操作。 ( 3 ) 调用业务操作，要么将它委托给处理程序。 ( 4 ) 助选择要显示给客户端的下一个视图。 ( 5 ) 视图返回给客户端。 2 1 2 m v c 的优点 大部分用过程语言比如as p ，p 口开发出来的w 曲应用，初始的开发模板就是 混合层的数据编程。例如，直接向数据库发送请求并用h r m l 显示，开发速度往 往比较快，但由于数据页面的分离不是很直接，因而很难体现出业务模型的样子 或者模型的重用性。产品设计弹性力度很小，很难满足用户的需求变化。m v c 要 求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模 型可以得到更好地体现【l “。 首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的 快速变化下，可能有多种方式访问应用的要求。例如：订单模型可能有本系统的 订单，也有网上订单，或者其它系统的订单，但对于订单的处理都是一样，也就 是说订单的处理是一致的。按m v c 设计模式，一个订单模型以及多个视图即可解 决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变， 硕上学位论文 也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用 于接口的使用。再次，由于一个应用被分离为三层，因此有时改变其中的一层就 能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动m v c 的模 型层。 控制层的概念也很有效，由于它把不同的模型和视图组合在起完成不同的 请求，因此，控制层可以说是包含了用户请求权限的概念i l “。 最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的 应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。 2 1 3 m v c 的缺点 m v c 的设计实现并不十分容易，理解起来比较容易，但对开发人员的要求比 较高。m v c 只是种基本的设计思想，还需要详细的设计规划l l ”。模型和视图的 严格分离可能使得调试困难一些，但比较容易发现错误。经验表明，m v c 由于将 应用分为三层，意味着代码文件增多。因此，对于文件的管理需要花费较多时间。 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循m v c ，使模型、视 图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行 效率。 2 2s t 瑚t s 框架体系结构 2 2 1s t r u t s 框架组成部分 s 衄i t s 是一个开源框架，包含了一系列相互的类、s e 州e t 和j s p 标记。s 仇如 框架是基于m v c 框架开发w 曲应用程序的具体应用。使用s 咖t s 框架可以将商业 逻辑、控制和数据显示功能模块区分开来，这样对其中一个模块的改动不会影响 到其它模块。使用这一框架，开发人员可以分别集中开发商业逻辑模块、应用过 程控制模块和数据显示模块，而不用担心这三个模块的耦合问题。 从m v c 的角度来分析s 恤l t s 框架中的各个组件，如图2 2 所示。a c t i 0 s e n ，l e t 负责接收来自浏览器的请求，并将h t t p 请求转发到框架中的其它对象，包括j s p 页。在初始化时，它对配置文件s t r u l s c o 赶g x 1 1 1 1 进行分析，然后根据其中定义的 映射转发相应的h 丌t 请求。在映射中必须指明请求的路径和对象类型。蜘o n 对象对请求进行处理并将响应返回到客户，或者指明控制应该转发到何处i l 。 a c t i o n 对象被链接到应用程序的a c t i o n s e r v l e t ，因此可阻访问它的方法。在进行控 制转移时，一个对象能够将一个或多个共享对象放置到请求、会话或应用的作用 域，从而间接地转发它们。 图22s t r u t s 框架 在图2 2 所示s 眦s 框架中，包括了客户端浏览器、控制器、业务逻辑、模型 和视图五个组成部分。 ( 1 ) 客户测览器( c l i e n tb r o w s e r ) ：来自客户测览器的每个哪请求创建一 个事件。w 曲容器将用个h t t p 响应作出回应。 ( 2 ) 控制器( c o n 廿o i l e r ) ：控制器接收来自浏览器的请求，并决定将这个请求 发往何处。就锄s 而言，控制器是以s e r v l e t 实现的一个命令设计模式。 s 仃u t s c o i l f i g x 1 l 文件配置控制器。 ( 3 ) 业务逻辑( b u s s 抽e s sl o 埘c ) ：s t m t s 框架本身没有提供模型组件，一般来 说，普通的j a v a 对象、e 晒组件、j a v a b e a n 组件都可以作为s m l 乜应用