（计算机应用技术专业论文）基于轻量级框架的企业应用快速开发平台的设计与实现.pdf

摘要 摘要 当今时代，是一个信息化的时代，信息全球化正在挑战今天的企业，企业为 了提高对市场的应变能力，需要不断加强对自身资源的掌控，需要切实地加强与 产业链上下游企业的联系。企业的业务控制和优化需要强大应用系统的支撑。近 年来，计算机技术的飞速发展，互联网的迅速普及，网络覆盖率和带宽的高速提 升，这些要素共同促进了基于w e b 的企业应用系统的蓬勃发展。 在企业应用系统开发上，j 2 e e 技术占有一个十分显著的地位。从最初经典的 e j b 架构，到最近流行的轻量级容器架构，众多的企业和开源社区在此做出了深入 的研究，开发出许多优秀的基于j 2 e e 的框架，比如s t r u t s 框架、s p r i n g 框架和 h i b e r n a t e 框架等。 本文探讨了j 2 e e 的框架及轻量级框架技术的发展，并分别针对表现层、业务 层和数据层进行了探讨，分析了其中的关键技术细节，另外对目前流行的一些常 用经典框架做了介绍。 基于上述的研究，文章提出了一种适应于企业应用快速开发的开发平台，其 以s p r i n g 框架为基础，采用s t r u t s 作为表示层框架，对多种数据层技术提供支持， 并整合多种企业应用服务解决方案作为扩展组件包。这个开发平台层次清晰，同 时包含了多种框架的优秀特性，采用了面向按口的设计原则，有效地提高了开发 效率，增加了软件的可扩展性和可维护性。 关键词：企业应用，轻量级框架，s p r i n g 框架，j 2 e e a b s t r a c t a b s t r a c t t h ep r e s e n te r ai sa ni n f o r m a t i o nt i m ea n dt h ei n f o r m a t i o ng l o b a l i z a t i o ni s c h a l l e n g i n ga l le n t e r p r i s e s e n t e r p r i s e sn e e dt os t r e n 垂h e nt h ec o n t r o lo ft h e i ro w n r c s o n r sa n dt h ec o n n e c t i o nw i t ho t h e re n t e r p r i s e si nt h ei n d u s t r i a lc h a i nu n c e a s i n g l y i no r d e rt oe n h a n c et h e i rm a r k e ts f f a i nc a p a c i t y t h ec o n t r o la n do p t i m i z a t i o no f b u s i n e s sp r o c e s sn e e dt h ef o r m i d a b l ea p p l i c a t i o ns y s t e mt os u p p o r t i nr e c e n ty e a r s ，t h e r a p i dd e v e l o p m e n to fc o m p u t e rt e c h n o l o g y , t h ee x p e d i t i o u sp o p u l a r i z a t i o no fi n t e m e t , t h es p e e d yp m m o t i o no fn e t w o r ko v e r l a yp e r c e n t a g ea n db a n d w i d t h , t h e s ee s s e n t i a l f ；l c t 0 稿p r o m o t e dt h ef l o u r i s h i n gd e v e l o p m e n to ft h ee n t e r p r i s ea p p l i c a t i o ns y s t e m w h i c hb a s e do nw e b t h ej 2 e et e c h n o l o g yh o l d sa ne x t r e m e l yr e m a r k a b l es t a t u si nt h ee n t e r p r i s e a p p l i c a t i o ns y s t e md e v e l o p m e n tt e c h n o l o g i e s f r o mt h ec l a s s i c a le i ba r c h i t e c t u r e , t o t h er e c e n t l yp o p u l a rl i g h t w e i g h tc o n t a i n e ra r c h i t e c t u r e , m a n ye n t e r p r i s e sa n do p e n s o u r c ec o m m u n i t i e sm a d er e s e a r c ho l li t , a n dh a v ed e v e l o p e dm a n yo u t s t a n d i n g f r a m e w o r kw h i c hb a s e do nt h ej 2 e et e c h n o l o g y , f o ri n s t a n c et h es t r u t sf r a m e w o r k , t h e s p r i n gf r a m e w o r ka n dt h eh i b e r n a t ef r a m e w o r k , a n d 8 0o n t h i sa r t i c l eh a sd i s c u s s e dt h ed e v e l o p m e n to fj 2 e ef r a m e w o r ka n dt h el i g h t w e i g h t f r a m e w o r kt e c h n o l o g y , a n ds e p a r a t e l ya i m e da tt h ep r e s e n t a t i o nl a y e r , t h eb u s i n e s s s e r v i c el a y e ra n dt h ed a t aa c c e s sl a y e rt oc a r r yo nt h ed i s c u s s i o n t h e na n a l y z e de s s e n t i a l t e c h n i c a ld e t a i l ，m o r e o v e rm a d et h ei n t r o d u c t i o nt os o m ep r e s e n tp o p u l a ra n d c o m m o n l yu s e dc l a s s i c a lf r a m e w o r k b a s e do nt h ea b o v er e s e a r c h ，t h ea r t i c l ep r o p o s e dt h ed e v e l o p m e n tp l a t f o r mw h i c h i sa d a p tt ot h ef a s td e v e l o p m e n to fe n t e r p r i s ea p p l i c a t i o n , i tt a k e st h es p r i n gf r a m e w o r k a st h ef o u n d a t i o n , u s e ss t r u t st ot a k et h ep r e s e n t a t i o nl a y e rf r a m e w o r k , p r o v i d e st h e s u p p o r tt ot h em a n yk i n d so fd a t aa c c e s sl a y e rt e c h n o l o g y , a n du s i n gm a n ye n t e r p r i s e s e r v i c es o l u t i o na st h ee x p a n s i o nm o d u l ep a c k a g e s t h i sd e v e l o p m e n tp l a t f o r mh a sa c l e a rl a y e ra r c h i t e c t u r e ，a n di tc o n t a i n sm a n yo u t s t a n d i n gc h a r a c t e r i s t i c so ft h o s e f r a m e w o r k s t h ef r a m e w o r ku s i n gt h ei n t e r f a c ep r i n c i p l eo fd e s i g n , e f f e c t i v e l y e n h a n c e st h e d e v e l o p m e n te f f i c i e n c y , i n c r e a s e s t h ee x t e n s i o na b i l i t ya n dt h e a b s t r a c t m a i n t a i n a b i l i t yo f s o f t w a r e i b y w o r d s ：e n t e r p r i s ea p p l i c a t i o n , l i g h t w e i g h tf r a m e w o r k , s p r i n gf r a m e w o r k ，j 2 e e m 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的说明并表示谢意。 躲# 魄中日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘厂允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名：，l 3 军生。导师签 日期： 第一章绪论 1 1 课题背景 第一章绪论 当今时代，是一个信息化的时代，信息全球化正在挑战今天的企业，企业级 应用系统的构建已经从传统的单机模式转向网络方向发展，这种企业级应用系统 的发展趋势要求当今的企业应用系统必然是以网络应用为基础，并根据不同企业 的内部情况在网络应用层面上加以扩展。 传统的企业应用开发模式是基于典型的客户朋臣务器( d s ) 系统。c s 系统是基 于2 层结构的，其中，在数据层和表示层( 数据逻辑层) 之间有着清晰的界限，这类 应用一般都是数据驱动的；它应用在客户机上，并且在企业中会配置一个数据库 服务器。虽然在这种结构下，企业内部可以共享数据，但是，随着业务处理系统 对系统提出更高的要求，它也逐渐暴露出许多缺点： 1 1“胖客户机”现象，不仅应用程序的性能受限于p c 机资源，网络流量 也增加了每一个客户端都要安装客户端软件，所以客户端的机器性能 就必须满足软件的最低要求，如果不能满足，程序也将不能运行；当每 次业务逻辑涉及到数据库操作的时候，数据需要在两层结构的客户端和 服务器端来回往返传递，如果有多个客户端同时对数据库操作，那么将 会造成巨大的网络开销，甚至会影响其他网络应用的程序的执行。 服务器负担过重，大数据量和多个用户并发使用将造成数据库的瓶颈， 使数据库性能急剧下降。每个客户端都要和数据库建立自己的连接，而 服务器端对于连接有一定的限制，为了提供更多的连接就需要增加更多 的投入。这种连接还存在着一个弊端，就是当某个客户端不再使用该连 接的时候，只要客户端程序一直运行，那么这个连接将不会被释放，即 不能为其他的客户端所使用。 3 ) 可维护性差。对应用程序的一个小改动都会涉及到把整个应用重新分发 给用户，如果用户数量庞大，那么应用程序的更新所带来的开销将是非 常巨大的；其次，如果一些用户来不及更新整个程序，而一些用户已经 及时作了更新，就会造成不同的客户使用的应用程序版本不一致，这种 应用程序版本的不一致性在某些时候也会造成整个系统的问题。 电子科技大学硕士学位论文 早期的w e b 系统只能提供一些简单的静态内容，远远不能满足人们的生活需 要，更不用说企业上的应用了。随着w e b 技术的不断发展，使得w e b 应用不再局 限于提供一些静态的内容、甚至也不满足于提供一些简单的动态内容。多层体系 结构正是适合w e b 应用的特点而发展起来的，与传统的客户机服务器模式相比， 这种多层模式一般分为三层：它在原有的客户机和数据库服务器之间增加了一个 中间层，称之为应用服务器层，专门负责处理应用逻辑，并具有事务管理、连接 缓冲等功能，而客户机只需通过图形界面和客户进行交互。这种应用服务器的存 在，使客户机变“瘦”了，把负荷均匀地分配给了应用服务器，并把客户机和数 据库服务器完全隔开，彼此独立。这样，对应用逻辑的修改只需在应用服务器上 一次完成，相对客户端而言完全透明，极大地方便了应用系统的部署及维护。在 很多情况下，为了避免客户方安装额外的程序及开发方便考虑，这个客户端采用 人们经常使用的浏览器，这也就是所谓的“浏览器服务器模式”( b s 模式) 。将应 用逻辑从另外两层中独立出来，将更适应日益复杂和不断变化的w e b 应用的需要。 在多层w e b 应用系统中，系统至少由三层体系结构组成：客户端( 浏览器) 一 w e b 服务器+ 应用服务器数据库服务器。客户端采用标准的网络浏览器，方便用 户访问信息；第二层包括w e b 服务器和应用服务器，所有的显示逻辑、应用逻辑、 控制逻辑都在这一层，系统的复杂性也主要体现在这一层；数据库服务器层存储 数据信息和数据逻辑，所有与数据有关的安全性控制、完整性控制、数据的一致 性以及并发操作等都是在该层实现的【1 1 。 在三层体系结构中，用户通过浏览器访问w e b 服务器；w e b 服务器是显示逻 辑的核心，它将信息组织成超文本，通过超文本标记语言( h t m l ) 和超文本传输协 议( h t t p ) 实现与浏览器的交互；而应用服务器负责处理应用逻辑，并进行事务管 理；数据库服务器负责处理数据逻辑，实现对数据库的读写操作。 通过应用服务器层，把应用逻辑从客户端和数据库服务器独立出来，向开发 者提供了一种创建、部署和维护大规模的w e b 应用系统的模块化方式，更适合开 发复杂的w e b 应用系统。 当前主要有两种实现企业级应用软件的平台：j 2 e e 和n e t 。j 2 e e 提供了一 种技术规范和丰富的基础服务组件，开发者基于这些规范和服务组件，采用特定 的开发框架进行应用程序的开发。n e t 是m i c r o s o f t 公司整合了己有平台和技术， 推出的统一平台。在此基础上，开发者可以选择v b n e t ，c 挣n e t 等不同的技术 进行应用程序的开发。由于j 2 e e 的开放性，有很多公司和开发者汇聚在一起推动 着j 2 e e 技术的发展，开源产品众多，源代码的普遍开放，使得j 2 e e 技术得到了 2 第一章绪论 迅速的发展，目前企业应用开发技术选择中倍受青睐。 在j 2 e e 领域中，出现了各种各样的开发框架。最早出现有经典的远程e j b 框 架、本地的e j b 框架，然后是s t r u t s ，w e b w o r kt a p e s t r y , s p r i n g 框架，还有数据库 访问的h i b e r n a t e , i b a t i s ，t o p l i n k 等框架。基本上针对不同的应用，不同的层次都 有很多相应的框架。这些框架整合了j 2 e e 所提供的基础服务组件，基于设计模式 和架构模式，提出了最佳开发实践。这些框架的出现极大推动了j 2 e e 技术，特别 是基于w e b 的j 2 e e 技术的发展。 应用这些框架满足企业级应用开发的时候，出现了一个问题，那就是如何来 合理高效地进一步整合这些具有特定功能的开发框架，从而实现出一个完整高效 的基于j 2 e e 和轻量级框架，面向w e b 的企业级应用开发平台。因此，合理地选择 不同的开发框架并将其整合为一个高效的企业级应用框架平台对于开发基于j 2 e e 的w e b 应用显得尤为迫切和必要。 企业级应用不同于其他的应用。它的开发任务非常巨大，通常需要一个团队 来持续开发很长一段时间。它的业务逻辑非常复杂。企业级应用软件要实现企业 的业务控制，而很多企业的业务都是很复杂的。企业级应用软件要整合企业的很 多不同资源，这也会增加业务的复杂性。很多企业级应用软件需要很高的处理效 率，同一时刻必须以极快的速度处理众多的并发访问。企业级应用软件用于支持 企业的正常运作，但企业的运作模式常常在不断的变化，企业的业务流程经常会 重组，新的业务不断的增加进来，不合理的业务被消除，企业级应用软件要不断 的进行扩展和升级来满足新的需求。 一个好的开发框架平台对开发企业级应用程序有着极为重要的意义。好的开 发框架平台能够最大限度地消除冗余，有效地降低开发量。好的开发框架平台能 够有效地降低各个模块，不同层次的祸合，不同的开发人员负责不同的开发任务， 从而使得开发人员能够各司其职，充分发挥各自的长处，有效地提高开发效率。 好的开发框架平台能够有效地使用己有的工具或成果来减少重复开发工作，从而 提高开发效率。 1 2 课题主要研究工作 我们的目标是实现一个快速开发j 2 e e 企业应用的软件框架或者是软件平台 w a f ( w e ba p p l i c a t i o nf r a m e w o r k ) 框架平台，这个平台抽取了大多数的j 2 e e 项目中设计( 非业务逻辑) 中的同类问题，选择目前流行的s p r i n g 框架为基础，对 3 电子科技大学硕士学位论文 各种表示层，数据层框架提供支持，同时融合各种企业应用服务的解决方案，研 究工作主要集中在： 1 ) 分析框架技术的发展，特别是j 2 e e 轻量级框架技术的特点和发展，阐述 了j 2 e e 技术设计的多层结构中表示层、业务层和数据层各层的技术特点， 另外介绍了每层中有代表性的常用框架。 2 ) 平台体系结构设计：根据企业应用软件的特点，先从整体上提出整个平台 的架构，将平台核心部分的层次划分为三层结构，即表示层、业务层和数 据层结构，然后设计对应每层的主要平台组件并实现。 3 ) 平台扩展组件包设计：根据企业应用服务各方面的需求，例如安全与权限 管理，规则引擎，邮件服务，业务流程管理等等，选择相应解决方案，并 将其作为扩展组件包融入我们的平台，以提高方便性，可用性，用户友好 度，使其能提供“o u t o f - b o x ”的服务。 4 ) 综合论述：从总体上对所做的工作进行了总结，并指出了论文存在的不足， 以及后继工作的展望。 论文的新颖之处在于： 1 ) 框架技术的发展大多是目前比较新兴的技术，论文本身研究的框架内容 如：m v c ，i o c ，h o p 和o r 映射都是当前比较流行的j 2 髓技术，尤其i o c 和a o p ，是下一代j 2 e e 技术的基础。 2 ) 平台的设计从整体上触及了j 2 e e 分层结构的各层( 表示层、业务层和数 据层) ，成为一个由上自下体式的解决方案。 3 ) 良好的融合了各种企业应用服务的解决方案，使之成为能提供企业应用整 体解决方案的开发平台，不仅降低了用户学习和开发难度，而且提高了开 发效率。 钔由我们自身积累的开发经验出发，将各种设计模式及最佳实践应用与框架 的设计中，给用户提供了一个良好的开发范例。 1 3 论文组织结构 第一章为引言，主要阐述课题的背景，研究工作以及说明本论文的组织结构。 第二章为框架技术分析，首先说明了框架的定义，什么是轻量级框架，以及其 优劣所在。然后对企业应用系统业务层开发技术进行分析，介绍了i o c ( 控制反转) 模式，然后阐述了h o p ( 面向方面编程) 的思想及其带来的改变和意义，最后针对 4 第一章绪论 成熟的开源框架s p r i n g 进行了介绍。 第三章为本课题研究成果一企业应用快速开发平台w a f 框架的设计和实现部 分，首先讲述了总体设计，然后分别从表示层，数据层这两个开发重点，分别对 表示层的m v c 模式，业务层的1 0 c 模式和a o p 技术，数据层的d a 0 模式和o r m a p p i n g 这些j 2 e e 应用开发中的关键技术进行了介绍分析，同时对当前流行的各种开源框 架进行了大概介绍。最后结合u m l 图和部分实现代码分别说明了表示层，数据层 的设计要求以及实现细节。 第四章为扩展组件包部分的设计与实现。介绍了针对企业应用开发所需的各种 企业特性的w a f 框架扩展组件包，如安全与权限管理，规则引擎，邮件服务等等。 第五章为结论，对本课题所作的工作进行了归纳总结，说明不足之处并对将来 的展望。 1 4 缩略语 a o p ：a s p e c to r i e n t e dp r o g r a m m i n g c r u d ：c r e a t e , r e a d ，u p d a t e , d e l e t e d a o ：d a t a a c c e s so b j e c t e j b ：e n t e r p r i s ej a v ab e a n i ( ) c ：i n v e r s i o no fc o n t r o l j 2 e e ：j a v a2p l a t f o r me n t e r p r i s ee d i t i o n 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 s p ：j a v as e r v e rp a g e s m v c ：m o d e l v i e w , c o n u o l l e r o o p ：o b j e c to r i e n t e dp r o g r a m m i n g o r m ：o b j e c t r e l a t i o n a lm a p p i n g p o j o ：p l a i no l dj a v ao b j e c t v o ：v 矾u co b j e c t 5 电子科技大学硕士学位论文 2 1 总体技术分析 第二章框架技术分析 伴随着软件开发技术的发展，在多层的软件开发项目中，可重用，易扩展， 而且是经过良好测试的软件组件，越来越为人们所青睐。这意味着人们可以将充 裕的时间用来分析、构建业务逻辑的应用上，而非繁杂的代码工程。于是人们将 相同类型问题的解决途径进行抽象，抽取成一个应用框架，也就是说框架是一些 经过实践证明的、能用来开发高效应用系统的技术。j 2 e e 项目就可以通过框架的 设计和运用来达到控制软件质量提高软件的生产效率。 2 1 1 什么是框架 设计模式对框架有如下定义：“af r a m e w o r ki sas e to fc o o p e r a t i n g c l a s s e st h a tm a k eu par e u s a b l ed e s i g nf o ras p e c i f i cc l a s so fs o f t w a r e ( 一 个框架，就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用 的设计) ”【2 】。 关于框架有多种不同但相似的定义： 框架是能被程序员在特定的计算机问题中使用、扩展或者定制的一组普遍 的，预先定制好的软件构建模块的集合。使用框架，开发者在开发应用项 目时无需每次从头开始。框架是从对象集合构建的，框架的设计和代码都 可以被重用。 框架是构成一类特定软件可复用设计的一组相互协作的类。 框架是一组具体表达了抽象设计的类，用于解决一类相关的问题。 框架是一个能被开发者插入他们自己的代码，并能提供大部分的通用功能 的应用架构 3 1 。 归纳上述定义，框架是整个或部分系统的可重用的设计，表现为一组抽象的 构件及构件实例间交互的方法；或认为，框架是可被应用开发者定制的应用骨架。 前者是从应用方面而后者从目的方面给出的定义。具体来说，一个框架由一组协 作类组成，阐明了整个设计、类间依赖及成员类的责任分布。这些类通常是抽象 6 第二章框架技术分析 类，实现细节放在具体子类中，构成一个抽象设计，不同的子类构成对设计的不 同实现。特定领域应用系统共有的设计因素由框架预先定义，应用开发人员只须 关注与特定应用系统的特有部分。框架刻画了其应用领域所共有的设计决策，所 以说框架着重于设计复用。 框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二次开发”， 实现为具体的应用系统。 框架不是“平台”。后者的概念更加广泛和模糊，人们说的一个平台，可以是 一种操作系统，一种应用服务器，一种数据库软件，一种通信中间件等等，因此 “平台”几乎成了所有系统软件的统称。在平台的大家族中，框架的概念可能与 近来人们常说的“应用平台”最为接近，但平台主要指提供特定服务的系统软件， 而框架则更侧重于设计、开发过程，或者可以说，框架通过调用平台提供的服务 而起作用。 框架不是工具包( t o o l k i t ) 类库( 1 i b r a r y ) a p i 目前流行的很多框架中， 就包括了大量的类库和a p i ，但是调用a p i 并不就是在使用框架开发。仅仅使用 a p i 时，开发者完成系统的主体部分，并不时地调用类库实现特定任务。而框架构 成了通用的、具有一般性的系统主体部分，“二次开发者”只是像做填空题一样， 根据具体业务，完成特定应用系统中与众不同特殊的部分。 框架不是架构( a r c h i t e c t u r e ) 。架构确定了系统整体结构、层次划分、不同 部分之间的协作等设计考虑。框架比架构更具体，更偏重于技术实现。确定框架 后，架构也随之确定，而对于同一种架构( 比如w e b 开发中的l l v c ) ，可以通过多种 框架( 比如s t r u t s 或s p r i n gm v c ) 实现。 框架是一个可复用的软件成分，它可以看作应用系统实现的一个半成品。它 为一类相似应用系统提供了共有结构的设计与实现，因此框架可以针对特定的应 用系统渐进行扩展。具体地说，框架有以下主要特点【4 】： 抽象性：框架抽象了特定领域中一组相似地应用系统( 或子系统) 设计与实 现地共有部分，并给出了这些部分的设计和实现。 可扩展性：由于框架抽象了一类相似应用的共同部分，开发者可以扩展这 些共同部分( 如抽象类) 实现特定的应用。 迭代性：框架开发过程本身具有迭代性。在使用框架的过程中，框架支持 领域的共性被不断发掘，因此框架需要反复的开发来完善其功能。 结构性：框架定义了特定领域中应用系统公共结构的设计和实现，开发者 在这个共同的结构上扩展其功能实现具体的应用，因此一个好的框架具有 7 电子科技大学硕士学位论文 明确清晰的层次结构，以便于复用和扩展。 可复用性：可复用性是框架的最根本的特点，也是框架具有上述特点的最 终目的，框架是一种大粒度的可复用资源，是从设计到实现层次的复用， 但它也必然地包括小粒度的复用一类的复用( 如对抽象类的继承) 。 2 1 2 轻量级框架 轻量级框架主要是指在j a v a 应用程序开发环境中简化的编程模型和更具响应 能力的容器。轻量级j a v a 旨在消除与传统j 2 e ea p i 有关的不必要的复杂性和限 制。它也将缩短应用程序的部署时间，这对于支持开发最佳实践( 如频繁单元测试) 非常重要。 嘲轻量级框架是与重量级框架相对比较而言的，重量级的典型代表就是 e j l b ，e j b 提供了一系列“重量级”企业级服务，并可以很好的集成e j b 容器( 所谓 容器，就是指应用代码的运行框架) 所提供的企业级服务，如j t a 等。虽然e j b 容器提供了较完整的服务策略，但e j b 容器的应用需要付出一定的代价，它主要 有下列缺点： e j b 代码不可以脱离e j b 容器。 e j b 容器启动缓慢。 部署e j b 十分麻烦，每个e j b 需要多个j a v a 文件，在正式部署前可能还 需要首先完成代码生成和编译。 应用代码只能运行在e j b 容器这一个环境里。 e j b 容器不能管理细粒度对象。 难以脱离e j b 容器进行钡9 试。 轻量级框架( 容器) 的出现就是致力于解决这些问题，并且融入了新的模式， 提供更加灵活和可选择性的服务。轻量级容器具有以下特性： 可以管理应用代码，而又不给应用代码强加对容器的依赖。例如，应该可 以无需修改的将遗留代码引入容器。这种特性一般叫做“非侵入性”：除 非绝对必须，否则基础设施不应该把对容器的依赖强加给应用代码。这也 使应用对象既可以在容器内，又可以在容器外运行，达到容器无关性。 可以快速启动。 不需要任何特殊的部署步骤。 最小限度的依赖a p i ，以确保可以运行在不同的环境里，例如w e b 容器， 8 第二章框架技术分析 独立的客户端，甚至是a p p l e t 。轻量级容器应该是纯j a v a 的，不应该依 赖于j 2 e e 。 将对象交给轻量级容器管理时，不管工作量还是性能开销都很小，因此可 以不仅可以在其中管理粗粒度的对象，而且也可以管理细粒度的对象。 相比较于重量级容器，例如e j b 容器，轻量级容器有着诸多优势： 脱离整体式容器。e j b 容器以一种“全有或全无”的方式提供企业级组件 模型，不能仅仅使用其中的一部分功能。对于典型的w e b 应用，如果能在 没有e j b 容器的情况下提供企业级服务，通常将大大简化系统架构。 提高代码复用度。由于代码不限于特定的使用环境，我们将可以在需要时 随意复用代码。 更好的面对对象。e j b 组件通常不是真正的对象，这是由e j b 组件模型的 特性决定的。而对于轻量级容器，由于对象的约束很少，我们通常可以更 好的实践面向对象。 提高了生产率。在轻量级容器里，应用代码通常类似于普通j a v a 代码， 受容器影响很小。由于几乎完全不依赖于重量级的a p i ，因此可以在任何 i d e 中方便的编写业务代码，从而大大提高生产率。 提高了可测试性。因为在容器外，例如普通的j u n i t 测试用例中就可以完 成钡4 试，所以可测试性也将大大提高。 2 2 业务层技术 一个成熟的架构中必须包括一个严格定义的业务服务层。这个层把业务逻辑提 供给客户端，例如w e b 用户界面，s w i n g 用户界面，或者是一个远程层。业务服务 层包括多个接口，每个接口都具有一个严格定义的契约。 在传统的j 2 e e 应用中，e j b 是最通用的构建业务层的技术。而在基于轻量级 容器的环境里，i o c 和a o p 技术得到了最广泛的应用。 2 2 1 i o c 模式 2 2 1 11 0 0 的概念 i o c ( i n v e r s i o no fc o n t r 0 1 ) 即控制反转，最早由a p a c h ea v a l o n 项目创始 人之一s t e f a n om a z z o c c h i 提出。 9 电子科技大学硕士学位论文 在一个典型的软件系统中，必定要把整个系统划分为着干个模块，由于人的理 解力有限，大多数开发者难以理解和把握过于复杂的系统。把软件系统划分成多 个模块，可以有效控制模块的复杂度，使每个模块都易于理解和维护。但在这种 情况下，模块之间就必须以某种方式交换信息，也就是必然要发生某种耦合关系。 如果某个模块和其它模块没有任何关联，即使只是潜在的或隐含的依赖关系，几 乎可以断定，该模块不属于此软件系统，应该从系统中剔除。如果所有模块之间 都没有任何耦合关系，其结果必然是：整个软件不过是多个互不相干的系统的简 单堆积，对每个系统而言，所有功能还是要在一个模块中实现，这等于没有做任 何模块的分解。 因此，模块之间必定会有这样或那样的依赖关系，永远不要想消除所有依赖。 但是，过强的耦合关系，如一个模块的变化会造成一个或多个其他模块也同时发 生变化的依赖关系会对软件系统的质量造成很大的危害。特别是当需求发生变化 时，代码的维护成本将非常高。所以，必须想尽办法来控制和消解不必要的耦合， 特别是那种会导致其它模块发生不可控变化的依赖关系。 在传统的模块实现中，由程序代码直接控制程序之间的关系。而在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 ed e p e n d e n c yi n j e c t i o n p a t t e r n 提出了i o c 的另一个新的名字：d i ( d e p e n d e n c yi n j e c t i o n ) ，即依赖 注入【们。 相对i o c 而言，依赖注入更加准确的描述了这种设计理念。从名字上理解，所 谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容 器动态的将某种依赖关系注入到组件之中。依赖注入的目标并非为软件系统带来 更多的功能，而是为了提升组件重用的概率的平台。 i o c 意味着将你设计好的类交给系统去控制，并为系统搭建一个灵活、可扩展 而不是在你的类内部控制。 2 2 1 21 0 c 实现策略 i o c 是一个很广泛的概念，它可以通过许多不同的方式来实现。其中有两种主 要的实现方式： d e p e n d e n c yl o o k u p ( 依赖查询) ：这是e j b 使用的方式。容器为所有组件 提供回调方法和查询上下文，它把责任扔给每个组件，让它们使用容器的 第二章框架技术分析 a p i 来查找资源和协作者。这种方式的i o c 被限制于容器层，应用程序代 码使用容器提供的回调方法来获取资源。 d e p e n d e n c yi n j e c t i o n ( 依赖注入) ：这是轻量型框架使用的方式。组件 本身不提供查询操作，而是提供普通的j a v a 方法，使得容器能够解析出 依赖关系。容器从整体上负责组装组件，把解析的对象传递给j a v e _ b e a n 属性或构造函数，使用j a v a b e a n 属性的方法叫做s e t t e ri n j e c t i o n ( 设 值方法注入) 或使用构造函数的方式叫做c o n s t r u c t o ri n j e c t i o n ( 构造 子注入) 。 图2 2 1 2 展示了几种不同类型的1 0 c 实现策略。 图2 2 1 2 不同类型的i o c 实现策略 e j b 和其它的j 2 e ea p i ，如s e r v l e ta p i ，提供了i o c 的依赖查询方式。容器 来管理对象的生命周期，而被管理的对象来负责实现自己的查询。例如，如果没 有使用任何e j b 之外的框架来实现它，你将需要使用j n d i 来查找其它的e j 8 和资 源。即使我们希望测试这个类，也不能脱离容器进行。如果这个类作为e j b 来实 现，我们将不能脱离e j b 容器使用它。在一定时期内依赖查询是必须存在的，因 此任何老牌的i o c 容器都支持它。然而，它具有的某些重要缺陷也意味着，如果 可能的话应该避免使用。 第二种i o c 实现策略，依赖注入，通常是更可取的。它让容器从整体上负责依 赖查询，在初始化时通过让被管理的对象暴露j a v a b e a n 的s e t t e r 方法或者构造 函数参数来实现在对象之间传递依赖。这种方式通常被称为基于语言的i o c ，因为 1 1 电子科技大学硕士学位论文 它没有依靠任何特定的容器a p i 或者接口 依赖注入配置的基本原则是应用程序对象不负责查找它们依赖的资源或协作 者。相反，i o c 容器负责配置对象，使资源查找从应用程序代码中分离出来交由容 器执行。 使用依赖注入，i o c 容器实现了垂直开发。容器负责查找资源，给业务对象提 供必须的资源。容器可以在不影响应用程序代码的情况下使用不同的方式重新配 置以便获得资源。 这种方式有下述优点： 彻底地从应用程序代码中删除查询操作。 不再依赖于容器的a p i ，我们只是面对j a v a 语言的概念。因此，在任何容 器外使用应用程序对象都是容易的。 不需要特殊的接口。 依赖注入可以帮助我们最小化应用程序代码对轻量型容器的依赖。实际上，对 大多数对象而言，这是可以彻底除去的。 使用s e t t e ri n j e c t i o n ，组件通过j a v a b e a n 属性传递对配置值和协作者的依 赖，这种方式建立在j a v a b e a n 标准之上。一般而言，依赖注入的概念不是特定于 j a v a 语言的，其它的语言也支持类似j a v a b e a n 的管理，比如c # 的属性。 使用c o n s t r u c t o ri n j e c t i o n ，组件通过构造函数参数传递依赖。这种方式的 依赖注入由p i c o c o n t a i n e r 团队在2 0 0 3 年中期发明，现在也被s p r i n g 和 p i c o c o n t a i n e r 之外的框架实现了。 相对于依赖查询而言，s e t t e ri n j e c t i o n 和c o n s t r u c t o ri n j e c t i o n 两种方 式都显示了巨大的进步。不论使用哪一种，实现依赖注入的基本原理是相同的。 他们二者之间也各有优劣。 s e t t e ri n j e c t i o n 的优势包括： 在i d e 方面，j a v a b e a n 属性得到了很好的支持。 j a v a b e a n 属性可以自我生成文档。 不需要任何代码，j a v a b e a n 属性可以被子类继承。 如果需要的话，标准的j a v a b e a n 属性编辑器也可以用来完成类型转换。 许多现存的j a v a b e a n 可以毫无修改的在面向j a v a b e a n 的i o c 容器中使 用。例如，s p r i n g 用户经常使用j a k a r t ac o m o n sd b c p 数据源。因为在 s p r i n g 容器中，它们可以通过j a v a b e a n 属性来管理。 如果对应每一个s e t t e r 方法给出相应的g e t t e r 方法，就可以读取组件当 第二章框架技术分析 前的配置状态。当需要持久化那个状态时，这显得特别有用。例如，使用 儿文件格式保存状态或将其存储在数据库中。使用c o n s t r u c t o r i n j e c t i o n ，没有办法发现当前状态。 s e t t e ri n j e c t i o n 可以为任何对象设置缺省值，也就是说并不是所有的 属性都需要在运行时提供。 劣势包括： 在任何情况下，都无法表达s e t t e r 方法调用的顺序。因此，我们有时需 要调用上一个s e t t e r 方法初始化组件之后，才可以调用商业方法。s p r i n g 提供了i n i t i a l i z i n g b e a n 接口来处理这种情况，它也提供了调用专有的 i n i t 方法的能力。然而，在容器之外，必须文档化这种约定才能确保正 确地使用。 在使用前，并不是所有的s e t t e r 方法都需要被调用。因此对象可能是部 分配置的。 c o n s t r u c t o ri n j e c t i o n 的优势包括： 在调用任何商业方法之前都能确保每一个管理对象具有一致的状态，即充 分地配置。不再需要调用初始化方法，这也是c o n s t r u c t o ri n j e c t i o n 的 主要动机。 与j a v a b e a n 方法相比，代码量会稍微少一点，但是在复杂度方面，它们 是相同的。 劣势包括： 虽然多参数构造函数方式也是j a v a 语言的特色，但是到目前为止，这种 方式使用得不那么普遍。因此，仅提供c o n s t r u c t o ri n j e c t i o n 的容器不 能运行许多有价值的已有代码，如c o m m o n sd b c p 连接池。 j a v a 构造函数参数不能通过自省机制使参数名可见。也就是说我们只能使 用参数索引，而不能使用友好的名字。当有几个相同类型的参数依赖的时 候，这会产生很大的问题。 在i d e 支持方面，构造函数列表的方式也没有j a v a b e a n 的s e t t e r 方式好。 长的构造函数参数列表和大的构造体也显得笨重。 因为构造函数不能自动地由子类继承，所以具体的继承可能变得有问题。 定义的构造函数调用了错误的超类构造