（计算机应用技术专业论文）基于spring框架的楼盘推介管理系统的研究与设计.pdf

摘要 通过开发基于w e b 的企业级应用来改变现代企业的信息交流方式、提升 企业的竞争力已经成为一个不可阻挡的潮流。j 2 e e 自诞生起，就专注于企业 级j a v a 市场，为构建企业级应用做出了不可磨灭的贡献。然而，对于大多数 中小型企业应用来说，传统的以e j b 为核心的j 2 e e 架构显得过于笨重，引入 了不必要的复杂性，而且它的o r 映射解决方案e n t i t yb e a n 被证明是不成功 的技术。在这种情况下，一个具有低侵入性的、能够让开发者和具体的j 2 e e 平台技术处于“松耦合”状态的、轻量级的w 曲框架是迫切需要的。 本文引入了来自开源社区的s p r i n g 框架，通过分析其原理和实现，剖析 了其两大核心机制i o c 和a o p ，指出基于这两个核心机制的s p n n g 框架完全 适用于一般w e b 应用的大部分功能和性能的要求。由于s p r i n g 本身“无侵入 性”的特点，它又可以方便地集成h i b e r n a t eo r 映射方案来取代e n t i t yb e a n 解决方案，集成优秀的w e b 层框架s t r u t s 。 在此基础上，本文提出以s p r i n g 框架为核心、集成h i b e r n a t e 和s t r u t s 的 w e b 应用开发方案，这种方案有以下优点：基于d i 机制的i o c 容器消除了 e j b 对业务逻辑层的强侵入性，使得基于s p r i n g 框架开发的应用消除了对具 体容器的依赖，实现了软件功能的动态配置；集成h i b e r n a t e 框架简洁明了地 实现了o r 映射功能，消除面向对象设计和关系数据库之间的“阻抗失谐” 现象，提高数据持久层的性能；集成s t r u t s 这种成熟的w e b 层框架，提高开 发效率。 最后将s t r u t s s p r i n g h i b e r n a t e 这种技术组合应用到房地产推广领域的楼 盘推介系统的实现中，对楼盘推介管理系统进行详细分析设计和实现，本文 给出了楼盘信息管理模块的具体实现过程。 关键词：s p r i n g 框架，i o c ，a o p ，s t r u t s ，h i b e r n a t e ，o r 映射 a b s t r a c t i t1 sat r e n dt ot r a n s f o r i l lt h ei n f o r m a t i o nc o m m u n i c a t i o nw a yo fm o d e m e n t e r p r i s e sa n dp r o m o t et h e i rc o m p e t i t i v ea b i l i t yt h r o u g he x p l o r i n gt h ee n t e r p r i s e a p p l i c a t i o no fw e b j 2 e eh a sc o n c e n t r a t e do nt h ee n t e r p r i s ea p p l i c a t i o ns i n c ei t s e x i s t e n c e ，w h i c hc o n t r i b u t e sal o tt ot h ec o n s t r u c t i o no fe n t e r p r i s ea p p l i c a t i o n h o w e v e r , t h et r a d i t i o n a lj 2 e ef r a m e w o r kw h o s ec o r ep o i n ti se j ba p p e a r sc u m b e r t om o s to fs e m s ( s m a l la n dm e d i ae n t e r p r i s e s ) w e ba p p l i c a t i o na n di n d u c t c e r t a i nu n n e c e s s a r yc o m p l e x i t y i na d d i t i o n ，e j b so rm a p p i n gs o i n t i o n - - e n t i t y b e a nh a sb e e np r o v e da nu n s u c c e s s f u lt e c h n o l o g y i nt h i ss i t u a t i o n ，i ti sn e c e s s a r y t oc o n s t r u c tal i g h t w e i g h tw e bf r a m e w o r kt h a ti se q u i p p e dw i t hl o wi n t r u s i v e n e s s a n da b l et om a k et h ee x p l o r e ra n dc o n c r e t ej 2 e ep l a t f o r mt e c h n o l o g yi na c o u p l i n gs t a t e t h i sp a p e rm a k e su s eo ft h es p r i n gf r a m e w o r ko r i g i n a t i n gf r o mo p e ns o u r c e s a n dd i s s e c t si t st w ok e ym e c h a n i s m s - - i o ca n da o p b ya n a l y z i n gi t sp r i n c i p l ea n d r e a l i z a t i o n i ta l s op o i n t so u tt h a tt h es p r i n gf r a m e w o r kb a s e do nt h e s et w ok e y m e c h a n i s m sc a l lb es u i t a b l ef o rt h em a j o r i t yr e q u e s to fg e n e r a lw e b a p p l i c a t i o ni n t h ef u n c t i o na n dp e r f o r m a n c e d u et oi t st r a i to f “n oi n t r u s i v e n e s s ”，t h es p r i n g f r a m e w o r kc a ne a s i l yi n t e g r a t eh i b e r n a t et or e p l a c ee n t i t yb e a n so rm a p p i n g s o l u t i o na n de x c e l l e n ts t r u t sf r a m e w o r k o nt h i sb a s i s ，t h i sp a p e rp u t sf o r w a r dak i n do fn e ww e ba p p l i c a t i o n f r a m e w o r kb a s e do nt h es p r i n gf r a m e w o r k ，w h i c hi n t e g r a t e sh i b e r n a t ea n ds t r u t s t h ew e bs y s t e mp o s s e s s e st h ef o l l o w i n ga d v a n t a g e s ：a tf i r s t ，i o cc o n t a i n e rb a s e d o nd im e c h a n i s ma v o i d ss t r o n gi n t r u s i v e n e s so fe j bt ob u s i n e s sl o g i c l a y e rw h i c h m a k e sa p p l i c a t i o no fs p r i n gf r a m e w o r ke l i m i n a t et h ed e p e n d e n c et oc o n c r e t e c o n t a i n e ra n dr e a l i z et h ed y l l a m i cc o n f i g u r a t i o no fs o f t w a r ef u n c t i o n ；s e c o n d l y , t h e f r a m e w o r ki n t e g r a t e dh i b e r n a t ea c h i e v e st h ef u n c t i o no fo rm a p p i n gs i m p l y , w h i c he l i m i n a t e st h e “i m p e d a n c e m i s m a t c h ”b e t w e e nr d b m s & o o da n d i m p r o v e st h ep e r f o r m a n c eo f d a t ap e r s i s t e n c el a y e r ；t h i r d l y , i ti n t e g r a t e st h em a t u r e w e bl a y e rf r a m e w o r k s t r u t s ，w h i c hi m p r o v e st h ee x p l o r i n ge f f i c i e n c y 1 1 f i n a l l y , t h et e c h n o l o g yc o m b i n a t i o no fs t r u t s s p r i n g h i b e r n a t ei sa p p l i e dt o d e v e l o p m e n to fe s t a t er e c o m m e n d a t i o ns y s t e mi ne s t a t er e c o m m e n d a t i o nf i e l da n d d e s i g n st h ee s t a t er e c o m m e n d a t i o nm a n a g e m e n ts y s t e mi nd e t a i l t h i sp a p e ra l s o p r o v i d e st h ec o n c r e t ed e v e l o pp r o c e s so fe s t a t ei n f o r m a t i o nm a n a g e m e n ts y s t e m k e yw o r d s ：s p r i n gf r a m e w o r k ，l o c ，a o p , s t r u t s ，h i b e m a t e ，o rm a p p i n g 1 1 1 武汉理工大学硕士学位论文 1 1 课题背景 第1 章绪论 目前，互联网风暴对人类的生产活动和生活方式产生巨大冲击，政府、 企业、以及个人都深受影响，在此背后i t 产业也面临一场变革基于c s 模式的传统应用向基于b s 的w e b 应用的变化。w e b 应用在系统的开放性、 可扩展性和维护便利性方面的优势锐不可挡，最为重要的是它满足了人们“随 时随地”获取信息的便利性。w e b 应用的规模和复杂度也日益升级，在软件 工程的实践中，人们越来越深刻地认识到系统总体结构设计的重要性已经远 远超过了特定算法和数据结构的选择，良好的体系结构对保障系统的成功至 关重要“。 w e b 应用系统b s 的三层或者多层框架结构设计主要包括用户界面的设 计、应用逻辑或事务逻辑的设计、数据库的设计三个方面，m v c 设计模式针 对b s 三层结构将系统划分为模型层、视图层、控制层。采用了m v c 模式构 件w e b 应用系统的体系结构，能够有效解决在w e b 应用系统开发过程中由于 系统结构的复杂程度较高带来的如何解决层次之间的耦合度、代码的易维护 性、应用框架的可重用性、组件的可重用性和不同层次的开发人员的技术分 工等诸多问题。因此m v c 模式适应了日益复杂的w e b 应用系统的设计需求。 j 2 e e 平台自诞生以来，就专注于企业级j a v a 市场，从很多方面来说，j 2 e e 都是一个伟大的成功：它成功地在从前没有标准的地方建立了标准；大大提 升了企业级软件的开放程度，因此得到了整个行业的开发者的广泛支持。但 是，j 2 e e 在一些方面的表现常常无法让人满意：过于复杂的应用程序、令人 失望的性能、难以测试、开发和维护的成本都非常高。j 2 e e 的核心组件e j b ( e n t e r p r i s ej a v a b e a n ，e j b ) 是一种复杂的技术，虽然很好地解决分布式应用 的问题，但是许多情况下也增添了比其商业价值更大的复杂性。在开发j 2 e e w e b 应用的过程中，易用性方面的问题尤为特殊，当开发者把m v c 模式在 j 2 e e 平台上实现时，现有的j 2 e e a p i 的复杂性使得开发者将大部分精力花费 在同资源交互的处理上，而对实际应用系统的关注却不多，这使得开发j 2 e e 应用效率低下的问题暴露无疑，很多w e b 应用都遭遇了毫无必要的过度工程。 武汉理工大学硕士学位论文 对于j 2 e e 应用系统中都存在毫无必要的复杂性，从系统质量角度来说， 带来大量不必要的代码，其编写、测试、维护都引发了更多的复杂工作，同 时提供了b u g 滋生的沃土，e j b 的高侵入性还使得排除b u g 的工作非常困难； 复杂的架构和代码表现出来的性能往往低下，层次太多、抽象太多、远程调 用太多( 这些都导致性能低下) 。从经济角度来说，这些复杂性导致凭空花费 余钱，并且还延误工期。 1 2 导致j 2 e e 应用复杂性的原因 很多j 2 e e 应用系统中之所以存在不必要的复杂性，都是若干常见原因作 祟，这些原因可以分成两类：文化性的和架构性的。 1 2 1 文化性原因 推动软件架构的，既包括技术因素，也包括人的因素、机构的因素以及 行业文化的因素，不幸的是，在j 2 e e 领域中，以上几种文化上的因素似乎联 合起来致力于为应用系统带来不必要的复杂性，使之成了个“依靠复杂性 为主的产业”。 1 厂商推动的复杂性。应用服务器厂商通常都会鼓励采用复杂的架构， 部分原因是为了给他们产品的复杂难用和昂贵价格提供借口。j 2 e e 应用服务器厂商尤其愿意鼓励人们滥用分布式对象，而他们的影响也 非同小可。 2 工具带来的复杂性。在该领域，有许多只适合于解决复杂性问题的工 具存在，当这些工具被开发者滥用的时候，得到的效果不是特定的工 具让开发工作更简单更方便，丽是带来了不必要的关于工具使用和维 护的复杂性。 3 企业错觉。很多企业觉得本企业的需求比较复杂、比较罕见，事实上， 很多应用系统解决的都是类似的问题，但是一旦相信自己的特殊性， 那么就可能会无视这个事实，容忍过度的复杂性。 4 人的因素。架构师和开发者的个人因素常常也对行业的复杂性起了推 动作用。很多人认为“傻瓜才需要简单，我是一个非常聪明的人”， 因此，出现了这样一种感觉：j a v a y j 2 e e 开发者才是真正的开发人员， 2 武汉理工大学硕士学位论文 代码的复杂性越高，才越是能符合他们卓尔不凡的地位。这就注定了 “尽可能简单地”做事是不可能的。同时还有一种现象是为获取专业 经验而开发，出于增长个人才智的需要，开发者们往往乐意使用e j b 来扩充自己的技术储备，而且招聘者也总是要寻求那些掌握了复杂技 术的人才。对于架构师来说，这些都是非常危险的。 1 2 2 架构性原因 在关于j 2 e e 架构问题中，不必要的复杂性常常是由以下几个方面造成 的：对e j b 的使用、对象分布化、模式病。 1 对e j b 的使用：e j b 是一项复杂的技术，对于一些特定的复杂问题 ( 比如分布式架构的实现) ，它提供了一种好的解决方案，但是究竟 使用e j b 带来的效益是减少复杂性、还是增加复杂性，取决于每个 应用系统在现实情况中面对了多少复杂问题。这就是要考察不同的应 用系统中使用e j b 的总体价值。 2 对象分布化。在j 2 e e 应用系统中，分布式对象经常是通过带远程接 口的e j b 实现的，因此可以说，分布化和e j b 是携手并进的。在很 多应用系统中，分布化很容易被过度使用。并且用e j b 实现分布化， 在表面上看起来比实际情况要容易得多，正是这种欺骗性，很多j 2 e e 开发者都受了哄骗，染上了一种虚假的安全感。实际上，无论采用哪 种技术，当编写一个包含分布式业务对象的系统时，都会遇到在计算 机领域内最棘手的若干挑战，如在不同服务器之间传输领域对象树、 专门采用传输层、不同节点之间代码同步问题、包含网络故障的异常 处理问题、测试的复杂性等等。 3 模式病。j 2 e e 中盛行模式，很多模式都是成熟的解决方案，确实能 够为我们在系统架构方面提供开阔的思路和有效的结果方案，但不少 专门用于j 2 e e 的模式，却是为了应付病入膏肓的架构设计而做出的 权宜之计，所以对于绝大多数应用系统来说，有些模式并不真正适用。 很多架构师和开发者热衷于把尽可能多的模式塞进自己的项目里，这 样做往往会导致危险的结果。 以上是导致在j 2 e e 应用出现不必要复杂性的两大方面原因，文化性原因 是很难从技术角度避免的，而架构性原因，则能够通过架构师理性的、科学 武汉理工大学硕士学位论文 的架构分析来避免。在本论文的第二章，将详细分析四种常见的j 2 e e 架构， 以及e j b 在架构中地位变化，以此来深层次分析问题，找到降低j 2 e e 应用开 发复杂性的有效途径。 1 3 来自开源社区的s p r i n g 框架 为了“降低j 2 e e 的复杂性”，开发人员不断寻找更简单的e j b 替代品， 探索一种更简单的开发框架能够让开发者和具体的j 2 e e 平台技术处于 “松耦合”的状态、能够构建轻量级的w e b 应用的w e b 框架。 o p e n s o u r c e 社区成员的共同努力使一个所谓的“后e j b 时代”成为了现 实。来自开源社区的s p r i n g 框架就是为解决j 2 e e 应用常见的问题提供简单、 有效的解决方案而设计的，s p r i n g 使用了诸如控制反转( i n v e r s i o no f c o n v o l ， i o c ) 和面向方面编程( a s p e c t o r i e n t e dp r o g r a m m i n g ，a o p ) 等较新的技术， 它用更加轻量级、更加灵活的基础设施取代了e j b ，并因此受益良多。很多 开发者已经在实际应用中使用了这种架构，并且得到了比传统架构更理想的 结果。由于其本身开放源代码，s p r i n g 有一个兴旺蓬勃的开发者和用户社群， 并且变得日益强大而且可靠，逐渐主导j 2 e e 社区开发w e b 应用朝着简单、 实用的方向发展。 1 4 本研究的内容和目标 鉴于以上的分析，本研究主要专注于以下几个方面： 1 通过对j 2 e e 架构的分析找出导致不必要复杂性的原因，对基于j 2 e e 的w e b 应用框架的发展做出总结。 2 详细研究s p r i n g 框架技术，包括控制反转的基本原理、i o c 容器的实 现方式和对a o p 的集成。 3 研究数据持久化方案o r m ，以及优秀的数据持久化工具h i b e r n a t e 。 4 研究w e b 层开发框架s t r u t s 。 5 将s t r u t s s p r i n g h i b e r n a t e 这种轻量级的w e b 框架应用到楼盘推介管 理系统中，实现楼盘信息管理、会员管理、系统管理等功能，构建一 个完整的、可维护的、可移植的w e b 应用系统。 研究目标是通过具体实践来验证基于s p r i n g 的轻量级w 曲框架能否降低 4 武汉理工大学硕士学位论文 传统的基于e j b 的j 2 e e 应用的复杂性，是否比传统的j 2 e e 应用程序更具备 可维护性、可测试性和可重构性，从而能够得出一个适合中小型企业w e b 应 用的、高效经济的w e b 应用开发框架。 1 5 本论文结构 本论文的结构如下： 第一章介绍课题背景。 第二章分析j 2 e e 的四种架构，对各种架构的优缺点进行总结，找到导致 j 2 e e 复杂性的原因e j b ，提出轻量级w e b 架构的设计模式。 第三章研究s p r i n g 框架技术及其对h i b e r n a t e 和s t r u t s 的集成。首先分析 轻量级容器和控制反转理论，以及i o c 容器的实现方法；其次详细分析s p r i n g 架构体系结构：然后研究数据持久化技术和s p r i n g 对h i b e r n a t e 的支持；最后 研究s p r i n g 对w e b 层框架的支持和对s t r u t s 框架的集成。 第四章对楼盘推介管理系统进行详细的分析和设计，将s t r u t s s p r i n g t t i b e m a t e 框架组合应用开发系统的实现中，构建出一个具有楼盘管理、 会员管理和系统管理等功能的楼盘推介管理系统。 第五章对本研究工作进行总结，分析系统研究成果和未来发展的方向。 武汉理工大学硕士学位论文 2 1j 2 e e 简介 第2 章j 2 e e 架构 从本质上来说，j 2 e e 就是一系列标准化的企业级服务如命名和目录 服务( j n d i ) 、为异构的事务性资源提供的标准事务管理接口( j t s 或j t a ) 、 连接遗留系统的标准机制( j c a ) 、资源池、线程管理等的集合体。e j b 组件模式使开发者能够通过一个特定的组件模型使用这些有价值的服务， j 2 e e 真正的威力在这些服务，它对这些服务的标准化对整个行业非常有益。， 在j 2 e e 应用系统中，有三种核心构件拼成一个完整的应用系统架构。它 们分别是：业务服务层、表现层和数据访问层。 本章从构件的角度来考察一下j 2 e e 架构，主要关注w e b 应用系统。w e b 应用系统和其它类型的应用系统之间的区别主要局限于表现层，服务层应该 是一致的。 2 2j 2 e e 架构 在本节考察四种不同的架构方案，分别是：经典的j 2 e e 远程e j b 架构； 本地e j b 架构；不带e j b 的特殊j 2 e e 架构；轻量级容器架构。下面对这四 种架构进行详细分析。 2 2 1 “经典的”j 2 e e 远程e j b 架构 在传统观念中，人们认为e j b 是实现j 2 e e 应用系统必不可少的部分、 j 2 e e 是一种分布式平台、s e s s i o n b e a n 和e n t i t y b e a n 在该平台中占有中心地 位，这些理念都在这种“经典的”j 2 e e 架构上得到了充分体现。这种架构的 体系结构如图2 1 所示。 在这个经典架构中，所有的业务对象都是带远程接口的无状态s e s s i o n b e a n ，运行在e j b 容器中。e j b 容器提供远程调用机制、事务管理、线程管 理，可能还有基于角色的安全服务。所有的数据访问都要通过e n t i t yb e a n 。 6 武汉理工大学硕士学位论文 e i s 层有一个或多个数据库再加上遗留系统组成，如果存在多个带事务的资源 图2 - 1 “经典”j 2 e e 架构 这个架构有以下优势： 1 支持分布式业务。本架构能够把业务对象分布在多台服务器上。 2 远程e j b 提供了一个严格定义的服务层，e j b 中包含的各种服务很 有应用价值。 3 提供一个共享的中间层，就能够支持各种类型的j 2 e e 客户端。 这个架构不足之处在于： 1 在要考察的四个架构中，这种架构无论在哪个方面都是负担最重的， 7 武汉理工大学硕士学位论文 有一些负载来自e j b 的共同问题，不过很多还是与分布式架构的特 性有关。 2 为了分布化，牺牲了o o 原则。 3 难以测试，因为业务逻辑通常编写在e j b 的实现类中，而这些类完 全依赖于e j b 容器。 这种带远程e j b 的架构，很多权威人士不推荐使用，对于w e b 应用系统 来说，这往往不是最佳选择。 2 2 2 本地e j b 架构 图2 - 2 本地e j b 体系结构 通过将远程e j b 替换成本地e j b 来简化和优化远程e j b 架构，就得到了 武汉理工大学硕士学位论文 本地e j b 架构。这种优化消除了对象的分布化，仅仅用e j b 组织业务对象、 提供事务管理之类的服务，既能从一个e j b 容器中得到好处，又不至于把应 用变成分布式的而招致过度的复杂性。相对于带远程e j b 的架构来说，是一 个很大的改进，其体系结构如图2 2 所示。 这个架构有以下优势： 1 提供e j b 容器事务管理与线程管理的各种好处，但没有分布式e j b 应用那么复杂。 2 ，不更改应用的基本设计，在这个体系结构中，只使一些对象成为e j b 来使用e j b 容器的服务。 3 没有远程方法调用或串行化，e j b 使用只强加相当小的性能开销。 4 可以根据需要有选择地使用实体组件。 这种架构的不足之处在于： 1 整个架构还是相当复杂，e j b 的很多负担都还存在，如依然要面对 e j b 部署和类装入的复杂性。 2 仍然存在可测试性问题：实现业务逻辑的那些类还是要依赖于e j b 容器，虽然访问e j b 稍微容易了一些，实现这些e j b 的难度一点没 有改变。 从图2 2 中可以看出，在这个架构中可以让同一个e j b 既有远程接口， 也有本地接口。采用这样的做法，就可能产生一个混血结构，这对于普通的 应用系统来说是不提倡的。 2 2 3e j b 架构的变体 对于上面所说的两种e j b 架构来说，还可能出现以下常见的变体： 1 用基于s q l 的j d b c 数据访问机制取代e n t i t yb e a n ，这是一种相当 常见的变体。 2 用某种透明持久化方案( 比如t o p l i n k 、h i b e r n a t e 或j d o ) 柬取代 e n t i t yb e a n 一 3 把业务逻辑从s l s b ( s t a t e l e s ss e s s i n b e a n ，无状态s e s s i o n b e a n ) 中重 构出来，放进p o j o ( p l a i n o b j e c tj a v a o b j e c t ，普通j a v a 对象) 里， 这也是一种明显的改进。尽可能地减少了业务逻辑对e j b 容器的依 赖，也就提高了代码的重用程度。 9 武汉理工大学硕士学位论文 4 用一个优秀的框架来简化e j b 寻址，而不是定制服务定位器。这种 简化机制最适合于本地e j b 。 从以上对带远程e j b 的j 2 e e 架构、本地e j b 架构和各种e j b 架构的变 体的分析中，可以看出它们存在的共同问题是： 1 需要e j b 容器。这也就意味着高端的应用服务器，比s e r v l e t 引擎管 理起来要复杂得多，也存在软件授权费用问题。 2 e j b 没有借用p o j o 助手类提供生命周期支持，额外需要一些细粒度 对象运行在会话门面之后、e j b 容器之中，为了管理e j b 后面的细 粒度对象，需要一个额外的基础架构。虽然e j b 部署描述符提供了 一种专门的机制，可以在x m l 中声明“环境变量”，然后就能够通 过j n d i 访问这些变量，但是要想达到非常细粒度的配置，这种做法 还是太过冗赘。 3 一旦把业务逻辑放进e j b 容器中，就很难停下来。如果有几个业务 需要完成的任务是e j b 编程模型禁止的( 比如创建线程、开启网络 连接、读取文件、调用第三方a p i ) ，就会出现问题了。 下面将要介绍两种不用e j b 的j 2 e e 应用架构，以此来和采用e j b 的j 2 e e 架构进行对比。 2 2 4 特制的非e j b 架构 事实上，不用e j b 的j 2 e e 架构不是新鲜事情，很多j 2 e e 应用项目都没 有使用e j b ，但还是成功了，对于w 曲应用系统来说尤其如此。对于不使用 e j b 的j 2 e e 架构来说，整体结构就没有那么多的规范性了，在目前常见的情 况下，这种结构通常是由w 曲容器定义的，之所以说是“特制的”，也正是因 为在很大程度上，系统的结构要有架构师自己结合各种技术进行选择组合。 这种架构的体系结构如图2 3 所示。 在这种架构中，所有的j a v a 对象都运行在同一个m 中，业务对象都是 p o j o ，运行在w e b 容器中，w e b 组件可以直接与业务接口交互。需要编程实 现事务管理，可以使用j t a ，也可以根据不同资源自行管理事务。与其它架 构一样，w e b 层通常也会由某种m v c 框架实现。数据访问有两种方法：用 o r 映射方案，或是使用j d b c 。e i s 层几乎与前边的架构一致。 1 0 武汉理工大学硕士学位论文 图2 - 3 特制的非e j b 架构 放弃了e j b ，这种架构的优点在于： 1 能够在s e r v l e t 引擎中运行，不需要带e j b 容器的专用服务器如 w e b l o g i c ，软件许可费用降低( 很多免费的可以产品可以使用) ，容 易管理，而且负载比较小。这对中小型企业来说是非常重要的。 2 方便在不同的应用服务器或s e r v l e t 引擎之间移植。 3 实现更为简单。比如，访问p o j o 业务对象通常比访问e j b 简单得多。 4 不需要那么多累赘的部署描述符。 5 代码部署周期要短，不需要e j b 的j a r 部署单元了，只需要打好w a r 包就够了。 这种架构的不足之处在于： 1 没有清晰的业务服务层。结果只能用特制的方法安排业务对象，这样 业务对象往往依附于w e b 层框架，比如s t r u t s 框架。 2 可能需要编写一些定制代码来对付e j b 早就解决了的问题。比如， 这个架构中就没有对声明式事务管理的支持，而这个在e j b 中是非 常方便的。 3 没有配置业务对象的标准方法，在不同的应用系统之间甚至在同 一个大型应用系统中缺乏一致性。每个应用系统都会有自己的一 武汉理工大学硕士学位论文 套做法：怎么访问业务对象、怎么保存配置、怎么解决事务管理等企 业级问题。 4 不能保证比e j b 更高的可测试性。 5 缺乏对远程调用的内置支持。 在这些不足中，最主要的一个潜在弱点就是缺少清晰的业务服务层，不 过可以通过强制实行规范来解决：要求开发者对业务接口的使用和对业务对 象的访问都必须保持一致。可以把这种架构称为“带业务组件接口的w e b 应 用系统”，采用这种架构的系统如果再加上一个“轻量级”容器，则收益更多。 2 2 5 “轻量级容器”架构 毫无疑问，即使没有e j b ，j 2 e e 应用也能成功，但是在前边所用的特制 的非e j b 架构中，完全抛弃了e j b ，也就意味着抛弃了j 2 e e 所提供的一些服 务，因此，更好的架构应该是能够享用e j b 提供的一些结构上的优势，同时 又不受困于e j b 的缺陷，把非e j b 架构提高到一个更高的水平。这就是要介 绍的轻量级容器架构。 被称为“轻量级容器”的架构，与特制的非e j b 架构不同。它与e j b 唯 一相像的地方就是：两者都用容器管理业务对象，然后再围绕着这个服务层 组织整个架构。在“轻量级容器”架构中，业务对象不是运行在e j b 容器中， 而是运行在“轻量级容器”中。轻量级容器没有和j 2 e e 绑定，所以它既可以 运行在w e b 容器里，也可以在一个标准的应用程序中运行，如果必要，还可 以运行在e j b 容器里。本架构如图3 - 4 所示。 在这个“轻量级容器”架构中，所有的j a v a 类都运行在同一个j v m 中。 从用户的角度看，w e b 层是由m v c 框架提供的，可以使用专用的m v c 框架， 如s t r u t s 或w e b w o r k 等，也可以由轻量级容器管理w e b 层本身。业务对象是 p o j o ，运行在轻量级容器里，与e j b 不同的是，业务对象无需依赖容器a p i ， 这意味着它们即使在容器外面，也是可以运行的。数据访问机制可以通过轻 量级的o r 映射层实现，该层能提供透明的持久化；e i s 层与其它架构是一 样的。 轻量级容器提供了一种管理、定位业务对象的办法，不需要j n d i 、定制 服务定位器、s i n g l e t o n 模式之类的东西。轻量级容器较e j b 容器而言，不仅 功能强大，而且更少的侵入性( 所谓侵入性，是指容器强制业务对象采用特 武汉理工大学硕士学位论文 定的接口) ，e j b 容器要求e j b 组件具有e j b 接口，而轻量级容器却往往能避 免这种强制性。 图2 4 “轻量级容器”架构 总的来说，这神架构的优点在于： 1 不需要e j b 容器，在不同的应用服务器之间具有高可移植性。 2 应用对象不依赖于容器的a p ! ，对象与合作者之间的依赖关系是通过 普通的j a v a b e a n 属性或构造函数的参数来体现。 3 与特制的非e j b 架构相比，本方案使用了一个轻量级容器，这样做 没有增加复杂性，而是降低了复杂性。开发者不需要编写任何针对特 定容器的代码。 4 如果轻量级容器支持a o p ( a s p e c t o r i e n t e dp r o g r a m ，面向方面编程， 将在第三章对其进行详细说明) ，那么就能提供非常成熟的声明式服 务。 5 很容易在应用服务器之外进行业务对象的单元测试，而且一些集成测 试也可以让j u n i t 来完成，测试驱动的开发变得容易了。 6 架构非常简单。 武汉理工大学硕士学位论文 这种架构的不足之处在于： 1 如果不附加一个远程门面的话，本架构不支持远程客户端，这一点与 本地e j b 和特制的非e j b 架构相似。但是这个门面很容易添加，尤 其是w e bs e r v i c e s 形式的远程调用越来越流行。 2 与e j b 技术规范相比，目前轻量级容器还没有什么标准。但是与e j b 对e j b a p i 的依赖性相比，轻量级容器中的应用对容器的侵入性要低 的多，这也正是轻量级容器独到的地方。 3 与e j b 架构相比，本架构对于开发者来说还有点陌生。这可能是妨 碍开发者采用本架构的一个非技术因素，但是这种情况正在改变之 中。 总的来说，“轻量级容器”架构具有“特制的非e j b ”架构的所有优点， 同时消除了后者的大部分缺点，是目前代表了w e b 应用框架发展的最新方案。 2 3 小结 在本章中，首先介绍了j 2 e e 应用系统中的核心构件，包括：业务服务层， 它对于应用系统的成败最为重要：表现层，这可以是一个u i ，也可以是一个 远程门面；数据访问层。然后从这些构件的角度出发，考察了四种j 2 e e 架构 类型：“经典的”j 2 e e 远程e j b 架构、本地e j b 架构( 使用本地e j b ) 、“特 制的”非e j b 架构、轻量级容器架构。分析了各自优势和不足之处，通过这 种对比，得出一个结论：e j b 及e j b 容器在j 2 e e 应用开发中是饱受非议的关 键点，很多的复杂性都是由于e j b 造成的，而轻量级容器则能有效地避开e j b 的复杂性，同时享用j 2 e e 平台提供的其它企业级服务。 轻量级容器架构是一种最近才出现的发展，只是在一些优秀的开放源代 码i o c ( i n v e r s eo fc o n t r o l ，控制反转) 容器诞生之后，这种架构才真正得到 了应用。幸运的是，目前已经有一些免费的轻量级容器，可选的有s p r i n g 框 架( w w w s p r i n g f r a m e w o r k o r g ) 和p i e o c o n t a i n e r ( w w w p i c o e o n t a i n e r o r g ) ，在下 面一章里，将详细介绍s p r i n g 框架，考察s p d n g 框架如何实现轻量级容器架 构的。 武汉理工大学硕士学位论文 第3 章s p r i n g 框架概述 3 1 轻量级容器和控制反转 从第二章对j 2 e e 架构的分析中可以看到，轻量级容器的引入对降低j 2 e e 应用复杂性的作用是非常大的。在此要具体介绍一下什么是容器，什么是轻 量级容器，轻量级容器的核心机制控制反转是如何实现的。 3 1 1 轻量级容器 所谓容器，是指应用代码的运行框架，应用对象( 大多数是业务对象) 在容器里运行，这也就是我们所说的“被容器管理”。有很多以容器为基础的 架构和模型，在经典的j 2 e e 架构中，e j b 容器就是管理j 2 e e 业务对象时最 常用的容器，w e b 容器则是用于管理s e r v l e t 及其相关依赖对象的。任何容器 都应该提供以下功能： 1 生命周期管理。容器必须将“创建新对象”的逻辑从使用者那里抽象 出来，更精密的生命周期管理可能包括诸多回调机制，在需要激活对 象、或者容器本身即将析构时，可以通过这些回调机制通知被管理的 对象。 2 查找服务。容器应该提供某种途径，用于获得受管对象的引用，容器 的查找功能将“对业务对象实现细节的了解”从使用者那里抽象出来 隐藏在容器内部，查找服务是容器的核心服务，也就是说，容器是管 理业务对象的工厂。 3 配置管理。容器需要提供统一的方法来配置运行其中的对象，并且允 许对象的参数化，简单的配置值应该从j a v a 代码中抽取出来。 4 依赖决议。容器不仅可以管理s t r i n g 、i n t 之类简单类型的配置，还可 以管理其中各个对象之间的关系。 以上都是任何容器都必须具备的服务，同时容器还可以提供一些增值的 服务，比如企业级服务( 为容器内运行的对象提供事务管理或其它声明性服 务) 、线程管理、对象池、集群服务、远程服务、可定制性和可扩展性等等。 武汉理工大学硕士学位论文 从轻量级容器要提供低侵入性的业务服务层管理的使命来说，轻量级容 器应该在具备任何容器都具备的功能的基础上，另外具有以下特征： 1 在不给应用代码强加对容器的依赖的前提下，可以管理应用代码。除 非绝对必须，否则基础设施不应该把对容器的依赖强加给应用代码。 这就使得应用对象既可以在容器内、又可以在容器外运行，达到容器 无关性。 2 最小限度地依赖a p i ，这就是提倡的“无侵入性”，以确保可以运行 在不同的环境中，例如w 曲容器、独立的客户端，甚至是a p p l e t 。 3 轻量级容器必须是纯j a v a 的，不应该依赖j 2 e e 。 4 不需要任何特殊的部署步骤。 5 将对象交给轻量级容器管理时，不管工作量还是性能开销都很小，因 此不仅可以在其中管理粗粒度对象，而且还可以管理细粒度对象。 轻量级容器对比于e j b 容器的优势体现在： 1 脱离整体式容器。e 喝容器可谓是超重量级的，它以一种“全有或者 全无”的方式提供企业级组件模型，不能仅仅使用其中的一部分功 能。对于典型的w e b 应用来说，如果能够在没有e j b 容器的情况下 提供企业级服务，通常将大大简化系统架构。而且一旦摆脱了e j b 容器，就可以同时摆脱高端应用服务器，不仅可以降低成本，而且也 避免了管理的复杂性。 2 提高代码复用度。使用e j ba p i 编写的程序只能在e j b 容器里面运 行，意味着在开发初期就已经假设了代码要在某个特定环境下运行， 然而这种假设通常是不明智的。 3 更好地面向对象。e j b 组件通常不是真正的对象，这是由e j b 组件 模型的特性所决定的，譬如说：所有的e j b ( 甚至包括本地e j b ) 的 粒度都必须相当粗，这对面向对象设计习惯增加了额外的约束；e j b 组件模型不支持继承，仅仅允许e j b 实现类的继承。而对于轻量级 容器来说，由于对对象的约束很少，通常可以更好地实践面向对象。 4 提高了生产率。在轻量级容器中，应用代码非常类似于普通j a v a 代 码，受容器影响极少，由于几乎完全不依赖重量级的a p i ，因此可以 在任何一个j a v ai d e 中方便地编写业务代码，从而大大提升了生产 率。 武汉理工大学硕士学位论文 5 提高了可测试性。因为在容器以外( 例如在普通的j u n i t 测试用例中) 就可以完成测试，所以可测试性得到很大提升。 在以上的分析中，一再强调要尽量避免代码对容器的依赖，然而在实际 应用中，只有非常简单的对象才能完全独立工作，大多数的业务对象都有依 赖关系，毫无疑问的是，对象需要查找其他的受管对象和资源，而这种查找 能力又是容器提供的，如何才能使受管对象不依赖于容器后者更小限度地依 赖容器? 这就要在是下一节耍介绍的控制反转和依赖注入的中找到答案了。 3 1 2 控制反转 控制反转( i n v e r s eo fc o n t r o l ，i o c ) 是框架中一个非常重要的概念，它