（管理科学与工程专业论文）基于mvc模式的spring框架的应用与研究.pdf

摘要 m v c 模式是众多设计模式中的一种，它为应用系统的开发提供了一种分层的体 系结构，即：视图层、控制层和模型层，这种三层结构随着1 2 e e 的出现使得m v c 在w e b 应用开发中得到了更为广泛的应用。但是由于j 2 e e 自身过于复杂，令人很 难把握和理解，同时复杂的结构又降低了系统的性能，因此出现了许多如s t r u t s 等轻量级的应用框架，但由于这些框架的出发点各不相同，对m v c 模式的实现方 式也大相径庭，因此它们自身都有着这样或那样的缺点。本文通过对s p r i n g 框架 的研究，探讨将不同框架进行整合的可能性，从而形成一个新的整合框架为w e b 应用开发提供更为有效的解决方案。 s p r i n g 框架是一个从2 0 0 3 年2 月才开始的开源工程，它主要来源于r o d j o h n s o n 所著的e x p e r to n e o n o n e3 2 e ed e s i g na n dd e v e l o p m e n t 一书，在此书 中r o dj o h n s o n 倡导j 2 e e 实用主义的设计思想，并随书提供了一个初步的开发框 架实现。在此基础之上，r o dj o h n s o n 进行了进一步的改造和扩充，使其发展为一 个新的开发框架，即：s p r i n g 框架。其出发点之一是要提供一种贯穿始终的解决 方案，将各框架的优秀技术整合到一个应用中，同时它自身提供的i o c 容器和a o p 支持，弥补了以往w e b 应用框架中的一些不足之处。 本文通过对上述内容的研究，利用s p r i n g 本身“无侵入性”的特点，将s p r i n g 与s t r u t s 框架进行整合，形成一个新的w e b 应用框架。该框架不仅拥有s t r u t s 灵活的视图层和控制层，而且兼有s p r i n g 的i o c 与a o p 机制，因而可以大大提高 业务层的重用性和扩展性。在应用实践中，使用整合后的框架，根据“面向接口” 的原则，设计并实施w e b 应用系统的开发，使其业务层的重用性和扩展性得到了 极大的提高。实践证明本文提出的整合后的w e b 应用框架，对应用系统的开发具 有非常重要的指导意义和实用价值。 关键词：s p r ；n g 框架；s t r u t s 框架；i o c ；a o p t h er e s e a r c ha n d a p p l i c a t i o no f t h es p r i n gf r a m e w o r kw h i c h b a s e do nm v c p a t t e r n a b s t r a c t m v cp a t t e r ni so n eo ft h ed e s i g np a t t e r n s ，i tp r o v i d e sa l a y e r e d s t r u c t u r ef o rt h ed e v e l o p m e n to fa p p l i c a t i o ns y s t e m ，w h i c hi n e l u d e sv i e w ， c o n t r o l l e ra n dm o d e l w i t ht h ea p p e a r a n c eo fj 2 e e ，m v ci su s e dm o r ew i d e l y i nt h ed e v e l o p m e n to fw e ba p p l i c a t i o n b u tj 2 e ei st o oc o m p l i c a t e da n dt o o h a r dt ob eh e l da n du n d e r s t o o d ，a n dt h ec o m p l i c a t e df r a m e w o r ka l s or e d u c e s t h ec a p a b i l i t yo fs y s t e ma tt h es a m et i m e s oi tc o m e sf o r t hal o to f 1 i g h t w e i g h tf r a m e w o r k ss u c ha ss t r u t s s i n c et h es p r i n g b o a r d so f t h e s e f r a m e w o r k sa r ed i f f e r e n ta n da l s oa b o u tt h e i rm e t h o d so nh o wt or e a li z e t h em v cp a t t e r n ，a l lo ft h e mh a v es o m ed i s a d v a n t a g e s t h i sp a p e rd i s c u s s e s t h ep o s s i b i l i t yt oi n t e g r a t ed i f f e r e n tf r a m e w o r k sb yi n v e s t i g a t i n gt h e s p r i n gf r a m e w o r k ，a n dh o p e st of o r man e wf r a m e w o r kw h i c hw i l lp r o v i d ea m o r ee f f e c t i v es o l u t i o nf o rw e ba p p l i c a t i o nd e v e l o p m e n t s p r i n gf r a m e w o r ki sa no p e ns o u r c ee n g i n e e r i n gw h i c hs t a r t e df r o mf e b r u a r y 2 0 0 3 ，i t m o s t l yr o o t e d i nt h eb o o k w r i t t e nb yr o d j o h n s o n i nt h i sb o o k ，r o dj o h n s o na d v o c a t e dt h ed e s i g n i d e ao fj 2 e ep r a c t i c a l i t y , a n dp r o v i d e dap r i m a r yd e v e l o p m e n tf r a m e w o r ki m p l e m e n t o nt h i sf o u n d a t i o n ，r o dj o h n s o nh a daf a r t h e rr e c o n s t r u c t i o na n de x t e n s i o nt od e v e l o p i ta san e wd e v e l o p m e n tf r a m e w o r k ，w h i c hi ss p r i n gf r a m e w o r k o n eo fi t sa i m si st o p r o v i d ec o n s i s t e n tp r o g r a m m i n gi na l lt i e r sa n dt h e r e b yi n t e g r a t et h ea p p l i c a t i o ns t a c k ， a n di tp r o v i d e si o cc o n t a i n e ra n da o p s u p p o r tt of e t c hu ps o m es h o r t c o m i n g so f t h e f o r m e rw e ba p p l i c a t i o nf r a m e w o r k s t h i sp a p e ru t i l i z e so n eo ft h es p r i n g sa d v a n t a g e s ，w h i c hi sc a l l e d “n o n 。i n v a s i o n ”， t oi n t e g r a t es p r i n ga n ds t r u t sa n dt h e nf o r man e ww e ba p p l i c a t i o nf r a m e w o r k t h i s f r a m e w o r kp o s s e s s e sn o to n l yf l e x i b l ev i e wa n dc o n t r o l l e ro fs t r u t sb u ta l s oi o ca n d a o po fs p r i n g ，s oi tc a ni n c r e a s et h ep o t e n t i a lf o rb u s i n e s sl a y e rr e u s ea n di t s e x t e n s i o ng r e a t l y i np r a c t i c e ，t h ei n t e g r a t e df r a m e w o r ki nt e r m so ft h ep r i n c i p l eo f “i n t e r f a c eo r i e n t e d ”，d e s i g n sa n da c t u a l i z e st h ed e v e l o p m e n to f w e ba p p l i c a t i o ns y s t e m ， i no r d e rt oi m p r o v et h er e u s ea n de x t e n s i o no fb u s i n e s sl o g i c a ll a y e r i tp r o v e dt h a tt h e i n t e g r a t e dw e ba p p l i c a t i o nf r a m e w o r kh a sav e r yi m p o r t a n td i r e c t i v em e a n i n ga n d p r a c t i c a lv a l u ef o rt h ed e v e l o p m e n to fa p p l i c a t i o ns y s t e m s k e yw o r d s ：s p r i n gf r a m e w o r k ；s t r u t sf r a m e w o r k ：i o c ；a o p 大连海事大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：本论文是在导师的指导下，独立进行研究工作所取得的成果， 撰写成博士，硕士学位论文 ! 基王m y 撞式的s 匦坠g 框袈的廛且量硒宜：。除 论文中已经注明引用的内容外，对论文的研究做出重要贡献的个人和集体，均已 在文中以明确方式标明。本论文中不包含任何未加明确注明的其他个人或集体已 经公开发表或未公开发表的成果。 本声明的法律责任由本人承担。 论文作者签名：备脚聊年j 月万日 学位论文版权使用授权书 本学位论文作者及指导教师完全了解“大连海事大学研究生学位论文提交、 版权使用管理办法”，同意大连海事大学保留并向国家有关部门或机构送交学位论 文的复印件和电子版，允许论文被查阅和借阅。本人授权大连海事大学可以将本 学位论文的全部或部分内容编入有关数据库进行检索，也可采用影印、缩印或扫 描等复制手段保存和汇编学位论文。 保密口，在年解密后适用本授权书。 本学位论文属于：保密口 不保密口( 请在以上方框内打“4 ”) 日 第1 章绪论 1 1 课题背景 互联网的迅速发展对人类的活动产生了巨大的影响，无论是政府、企业抑或 是个人，莫不如此。人们对互联网的青睐，促进了网络的飞速发展，新理论、新 技术层出不穷。但是当人们的要求不断的增长，使得软件开发的复杂性也不断的 上升。针对这些问题，人们又不断的发展相应的解决方案，出现了许多的设计模 式。其实，设计模式来源于建筑学，所谓“他山之石，可以攻玉”，在i t 业里， 设计模式为许多重复出现的问题，提出了既优雅又实际的解决方案【”。 m v c 模式是众多设计模式中的一种，它提供了一个原则，可以按照模型、表达 方式和行为等角色把一个应用系统的各个部分之间的耦合解脱、分割开来。这种 体系结构为复杂的w e b 应用提供了清晰的层次划分，同时这种三层结构的理念随 肴7 2 e e 的出现在w e b 应用开发中得到了更为广泛的应用。然而m v c 模式仅仅为w e b 应用提供了对应的设计方法，并没有提供具体的技术实现，为此产生了众多的w e b 应用开发框架，它们大多使用m v c 模式作为指导思想，各自定义不同的规范，提 供不同的技术细节，以便使w e b 开发更为有效快捷。 正因为w e b 应用框架能够给应用提供良好的结构，使得人们无须再想法设法 解决一些经典的问题，而且系统的架构更统一、更容易理解，w e b 框架在如今的企 业级应用开发中，往往扮演了重要的角色。从开发角度考虑，具体w e b 框架的开 发模型决定了整个开发过程。因此，正确选用w e b 框架对于项目的成功往往起到 了很关键的作用。 1 2 流行框架分析 对于应用开发来说，降低开发成本、缩短开发周期、提高可维护性和运行效 率是其追求的目标。对于w e b 开发来说也不例外。j 2 e e 平台的出现在一定程度上 减少了w e b 应用开发的成本和复杂度，但是其本身过于复杂的体系结构、难预测、 开发和维护成本的高昂，使得j 2 e e 的架构方案常常无法让人满意。为此，现在许 多的w e b 应用框架提供了更为便捷的方案，目前较为流行的框架有很多，这里我 们只列举其中的几个框架作为参考： s t r u t s 框架 2 】：s t r u t s 是一个老牌的w e b 应用框架，也是现在应用最多的丌 发框架，它是由a p a c h e 软件基金开发并维护的免费开源软件。s t r u t s 具有高可配 置性和一个不断增长的特性列表。它包括个前端控制组件、一系列的动作类、 动作映射、处理x m l 的实用工具类、服务器端j a v ab e a n 的自动填充、支持验证 的w e b 表单。国际化支持，生成h t m l 等。s t r u t s 的主要缺点是缺少完善的权限设 计，而且没有数据层的支持，它的使用必须完全依赖于具体的框架类，比如它必 须对a c t i o n ，a c t i o n f o r m 的继承实现和w e b 层的s e r v l e t 对象以及s t r u t s 本身 的a p i 紧耦合等。事实上，s t r u t s 不能将领域对象作为f o r m b e a n 使用，带来了很 多额外的f o r m b e a n ，导致了不必要的复杂性。它的视图部分也只支持j s p ，不能 很好的支持其它视图技术。 t a p e s t r y 框架【3 】：t a p e s t r y 也是j a k a r t aa p a c h e 基金会下面的一个子项目。 它是一个开源的基于s e r v l e t 的应用程序框架，它使用组件对象模型来创建动态 的，交互的w e b 应用。一个组件就是任意一个带有j w c i d 属性的h t m l 标记。其中 j w c 的意思是j a v a w e hc o m p o n e n t o 。t a p e s t r y 使得j a v a 代码与h t m l 完全分离， 利用这个框架开发大型应用变得轻而易举。并且开发的应用很容易维护和升级。 t a p e s t r y 支持本地化，其错误报告也很详细。但t a p e s t r y 的主要缺点是开发文档 数量稀少而且内容不详尽，加之其自身的流转控制功能较为薄弱，所以至今缺少 运用了此框架的企业级应用。 t u r b i n e 框架【4 】：t u r b i n e 是由a p a c h ej a k a r t a 开源开发小组提供的服务器端 j a v aw e b 构架。任何支持s e r v l e t 标准的服务器都可以平稳的运行t u r b i n e ( 例 如：t o m c a t ，r e s i n ，w e b l o g i c ) 。t u r b i n e 的开发包是t d k ( t u r b i n ed e v e l o p m e n t k i t ) ，它是由一组j a k a r t at u r b i n e 子项目组成，列举如下：视图层采用v e l o c i t y 和j s p 。数据层采用的是t o r q u e 和p e e r s ，利用x m l 技术将关系型数据库和j a v a c l a s s 互相映射。控制层采用t u r b i n e 自带的应用框架。t u r b i n e 最富有特色的部 分是拥有提供了大量w e b 系统服务功能的s e r v i c ef r a m e w o r k 。但是t u r b i n e 也有 一些明显的弱点，首先它不依附于j 2 e e 标准，因为它的项目启动时间比j 2 e e 标 准形成要来的早，这样t u r b i n e 就有被边缘化的危险；其次它的导航性比较差， 页面管理有一些凌乱。 1 3 课题的研究内容 正如我们看到的，尽管这些框架在不同的领域中具有各自的优势，但它们对 m v c 的实现都有蓿不尽人意的地方。如：s t r u t s 框架，虽然它提供了非常灵活的 控制层和视图层，但缺乏对业务层的支持，但是整体可维护性、可测试性、可复 用性多取决于如何处理和实现业务对象。如果能够使用某种方式，将不同框架的 优势融合到一起，并针对单一框架的不足使用其它架构对其进行相应的补充，就 可以为w e b 应用开发提供更为有效的解决方案。 本文的研究内容就是耍通过对s p r i n g 框架的分析，针对s t r u t s 框架缺乏对 业务对象管理的不足。将s p r i n g 与s t r u t s 进行整合，目的是提出一个框架整合 方案，进而形成一个新的框架结构。使得此框架在前端拥有s t r u t s 框架所提供的 灵活的控制层和视图层，同时又s 够利用s p r i n g 中的i o c 容器和a o p 支持，使得 实际的应用系统在业务上有着良好的可扩展性。由此，本文的预期目标为： ( 1 ) 通过对s p r i n g 框架的研究，探讨s p r i n g 与s t r u t s 整合的实现方法，并 将两者集成到一起，从而形成一个新的体系结构。同时验证此框架结构的可用性。 ( 2 ) 将新的框架应用到实际中，指导实际项目的实现，从而使实际系统能够 拥有灵括的视图层与控制层，并且使实际系统在业务层具有良好的可扩展性。 1 4 文童结构 第一章：介绍课题的背景及课题的预期目标。 第二章；简介m v c 模式与s p r i n g 框架，包括m v c 模式的理念，m v c 模式 的发展以及它的优点。同时简要介绍了s p r i n g 框架的基本构成，以及它对m v c 模式的实现和s p r i n g 框架的核心内容，其中s p n n g 框架的核心内容包括：i o c ( 控 制反转) 模式和a o p ( 罚向方面编程) 。 第三章：实现s p r i n g 与s t r u t s 的整合，形成新的框架结构井验证其可用性。 包括简要介绍s t r u t s 的基本结构及其优势，探讨s p r i n g 与s t r u t s 整合的实现方式， 给出相应的技术细节，并使用整合后的框架对一个既有系统进行改进以验证新框 架的可用性。 第四章：使用整合框架来指导实际系统的实现。包括对实际系统的分析、设 计，及使用整合框架完成系统的实现。从而验证整合框架在实践中意义，同时验 证以此框架完成的系统在业务层所具有的可扩展性。 第五章：总结本次毕业设计的工作。 第五章：总结本次毕业设计的工作。 2 1 m v c 模式 第2 章w e b 框架模式的研究 2 1 1m v o 模式简介 m v c 英文即m o d e l - v i e w c o n t r o l l e r ，它是目前非常流行的一种软件设计模式。 早在7 0 年代，i b m 就推出了s a n f r o n s c i s i c o 项目计划，其实就是m v c 设计模式的 研究。m v c 首先被应用在s m a l i t a l k 一8 0 环境中，是许多交互和界面系统的构成基 础，甚至在m i c r o s o f t 的m f c 基础类中也遵循了m v c 的思想。现在随着网路的飞 速发展，m v c 模式在w e b 应用开发中也得到了广泛的应用。 m v c 的设计思想是将应用的输入、处理和输出流程进行强制的分离。这样一个 应用被分成：m o d e l ( 模型) 、v i e w ( 视图) 、c o n t r o l l e r ( 控制) 三个层次。 图2 1m v c 模式 f i g 2 1m v cp a t t e m 视图( v i e w ) ：代表用户交互界面，对于w e b 应用来说，可以概括为h t m l 界面 4 但有可能为x h t 嘶l 、x m l 和a p p l e t 。随着应用的复杂性和规模性，界面的处理也变 得具有挑战性一个应用可能有很多不同的视图，m v c 设计模式对于视图的处理仅 限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程 的处理a 业务流程的处理交予模型( m o d e l ) 处理。比如一个订单的视图只接受来自 模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。 模型( m o d e l ) ：就是业务流程状态的处理以及业务规则的制定。业务流程的 处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处 理结果。业务模型的设计可以说是 v i v c 最主要的核心。目前流行的e j b 模型就是 一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便 充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种 模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来 说，就可以专注于业务模型的设计。m v c 设计模式告诉我们，把应用的模型按一定 的规贝抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。 抽象与具体不能隔得太远，也不能太近。m v c 并没有提供模型的设计方法，而只告 诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象 编程来做比喻，m v c 定义了一个顶级类，告诉它的子类你只能做这些，但没法限制 你能做这些，这点对编程的开发人员非常重要。 业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象 的数据保存( 持续化) 。比如将一张订单保存到数据库，从数据库获取订单。我们 可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。 控制( c o n t r o l l e r ) ：可以理解为从用户接收请求，将模型与视图匹配在一起， 共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一 个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。 控制层并不做任何的数据处理。例如，用户点击一个链接，控制层接受请求后，并 不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要 求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多 个模型【5 - 1 们。 2 1 2m v c 的优点 大部分用过程语言比如a s p 、p h p 开发出来的w e b 应用，初始的开发模板就是 混合层的数据编程。例如，直接向数据库发送请求并用h t m l 显示，开发速度往往 比较快，但由于数据页面的分离不是很直接，因而很难体现出业务模型的样子或者 模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。m v c 要求对 应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可 以得到更好地体现【1 ”。 首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的 快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的 订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就 是说订单的处理是一致的。按m v c 设计模式，一个订单模型以及多个视图即可解 决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变， 也易于维护。其次，由于模型返回的数据不带任何显示格式，因而这些模型也可 直接应用于接口的使用。 再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用 的改变。一个应用的业务流程或者业务规则的改变只需改动m v c 的模型层。 控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成 不同的请求，因此，控制层可以说是包含了用户请求权限的概念。 最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的 应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。 2 3s p r i n g 框架简介 在我们进入具体的细节之前，先整体的了解一下s p r i n g 框架，包括它的来历、 出发点、以及其基本的构成。 2 3 1s p r in g 的出发点 s p r i n g 框架起源于其缔造者r o dj o h n s o n2 0 0 2 年所写的 e x p e r to n e o n o n e j 2 e ed e s i g na n dd e v e l o p m e n t 一书的基础代码。在这本书中，r o d 介绍他自己 的j 2 e e 经验，并且解释了e j b 为何常常葬送了整个项目。他坚信一种轻量级的， 基于j a v a b e a n 的框架完全可以满足大多数开发人员的要求。2 0 0 3 年2 月，他把所 描述的框架在s o u r c e f o r g e n e t 公开了源代码，后来，这个框架就是演变成了著 名的s p r i n g 框架【1 2 1 。 在s p r i n g 之前，许多专用框架在各个壤域都有着很多出色的解决方案，比如： w e b 框架、持久化方案、远程调用工具等等，然而将这些工具整合成一个全面的架 构确困难重重，甚至成为一种负担。s p r i n g 的目标是提供一种贯穿始终的解决方 案。将各种专用框架整舍成一个连贯鲍整体构架。在这种意义上说，s p r i n g 框架 就像一个黏合剂，将各个领域出色的解决方案黏合到一起，构成一个新的架构， 更好的为应用服务【1 3 】。 s p r i n g 力求不强女日任何架构风格，蔼是把选择的权利留给开发者，允许用户 使用其中的单项功能，而不是把整个框架强加给用户。s p r i n g 中的许多特性，如： 7 d b c 抽象层或者h i b e r n a t i o n 集成，都可以作为一个库单独使用，当然也可以作 为s d r i n g 整体方案的一个部分。从这里我们可以看出，s p r i n g 为我们提供了极大 的灵活性，我们即可以选择不同领域优秀的工具，又可以选择s p r i n g 本身的各个 部分。下面我们来看一下s p r i n g 的基本结构。 2 3 2s p r i n g 的基本结构 下图为s p r i n g 框架的基本结构图： 图2 zs p r i n g 框架的基本结构 f i g 2 2b a s i cs t r u c t u r eo fs p r i l l gf r a m e w o r k 由图中所示s p r i n g 框架有7 个基本模块，这7 个模块是相互独立的，每个模 块都有一个对应的j a r 文件。其中【“l ： s p r i n gc o r e ：s p r i n g 框架最为基础、最重要的模块。它提供l o c 容器，即依 赖注入。 s p r i n gc o n t e x t ：提供b e a n 的访问方式，并且添加了用于资源绑定、事件移 植、资源装载和透明的装载上下文等功能。 s p r i n gd a o ：提供j d b c 的抽象层，使得开发者不用去编写非业务功能的j d b c 代码，同时提供它同时能够提供编程方式和声明方式控制事务。 s p r i n go r m ：为当前流行的o rm a p p i n g 技术提供集成。 s p r i n ga o p ：实现了a o p 联盟定义的a o p 编程实现。 s p r i n gw e b ：提供面向w e b 应用集成的功能。这里的集成是初步的集成。 s p r i n gw e bm v c 提供m v c 的实现。 2 4s p rin g 对m v c 的支持 2 4 1s p r i n g 的实现模式 对于现有较成熟的m o d e l - v i e w c o n t r o l ( m v c ) 框架而言，其解决的主要问题无 外乎下面几部分 1 2 - 1 5 】： ( 1 ) 将w e b 页面中的输入元素封装为一个( 请求) 数据对象。 ( 2 ) 根据请求的不同，调度相应的逻辑处理单元，并将( 请求) 数据对象作 为参数传入。 ( 3 ) 逻辑处理单元完成运算后，返回一个结果数据对象。 ( 4 ) 将结果数据对象中的数据与预先设计的表现层相融合并展现给用户。 各个f f g c 实现固然存在差异，但其中的关键流程大致如上。 s p r i n g 的w e b 框架所支持的是m v c 模式的第二种模式，即上文提到的j s p 模 型二。其具体的实现是围绕分发器设计的，d i s p a t c h e r s e r v l e t 将请求分发到不同 的处理器，框架还包括可配置的处理器映射，视图解析，本地化，主题解析，支 持文件上传等等，其具体的类如下图所示： a h f i r a c ，u r l b a s , 耐v i e w 卜叫a b j t r a c t v h i t t p s e r v l e t b e a n a p p “。0 玉。 凸 牟 会 f r a m e w o r k s e r v l e t u 一，。 ) v - e | | e l ， , ”q h l c a u o n l o n m xe l k j s t l v i e w馕掣罕9 孵r 面鞯i t “町“。”“。 陋写娑们。胁莨卑舻m 一e 胁n d l e r a d 掣e r i 甲 r e s 。r e s 山e r u n b a s e ( ，、w 耻s 。l v c rl 8 ”。批尝州唧”曙 牟t v e r s m p i “： f n g 图的 实现模式 s 控制器：缺省的处理器是一个简单的控制器() 接口，这个接口 仅仅定义了h a n d l e r e q u e s t (，) 方法。我们可以实 现这个接口生成应用的控制器，但是使用提供的系列控制器实现会更好 一些，比如和。在实际的应 用中控制器一般都从它们继承。 视图：的视图解析相当灵活。一个控制器实现甚至可以直接输出一个 视图作为响应，这需要使用返回。在一般的情况下， 使用一个 实例包含视图名字和模型映射表，模型映射表提供了 的名字及其对象( 比如命令对象或表单对象，引用数据等等) 的对应关系。视圈 名解析的配置是非常灵活的，可以通过 的名字，属性文件或者你自己的 来实现。抽象的模型映射表完全抽象了表现层，没有任何限制： ， ，或者其它的技术任何表现层都可以直接和集成。模型映射 表仅仅将数据转换成合适的格式，比如 请求属性或者模版模型等。 模型：对于模型部件，提供了一个容器，使用它我们可以将各个 类进行组装，它全权负责依赖查询，受管对象只需暴露 的 方法 或者带参数的构造子，让容器可以在初始化时组装对象的依赖关系。这样 容 器负责查找组件需要的资源，并将必要的资源注入到业务对象中。于是，只要对 容器重新配置，有不同的方式获得资源，就可以让组件获得不同的资源，而不必 修改代码。 2 4 2s p r i n gm v c 框架的特点 s p r i n g 框架所提供的m v c 有着以下的一些特点【1 6 1 ： ( 1 ) 清晰的角色划分：控制器，验证器，命令对象，表单对象和模型对象； 分发器，处理器映射和视图解析器等。 ( 2 ) 直接将框架类和应用类都作为j a v a b e a n 配置，包括通过应用上下文配置 中间层引用，例如，从w e b 控制器到业务对象和验证器的引用。 ( 3 ) 可适应性，但不具有强制性：根据不同的情况，使用任何你需要的控制 器子类( 普通控制器，命令，表单，向导，多个行为，或者自定义的) ，而不是要 求任何东西都要从a c t i o n a c t i o n f o r m 继承。 ( 4 ) 可重用的业务代码，而不需要代码重复：你可以使用现有的业务对象作 为命令对象或表单对象，而不需要在a c t i o n f o r m 的予类中重复它们的定义。 ( 5 ) 可定制的绑定和验证：将类型不匹配作为应用级的验证错误，这可以保 存错误的值，以及本地化的日期和数字绑定等，而不是只能使用字符串表单对象， 手动解析它并转换到业务对象。 ( 6 ) 可定制的处理器映射，可定制的视图解析：灵活的模型可以根据名字值 映射，处理器映射和视图解析使应用策略从简单过渡到复杂，而不是只有一种单 一的方法。 ( 7 ) 可定制的本地化和主题解析，支持7 s p ，无论有没有使用s p r i n g 标签库， 支持j s t l ，支持不需要额外过渡的v e l o c i t y ，等等。 ( 8 ) 简单而强大的标签库，它尽可能地避免在h t m l 生成时的开销，提供在标 记方面的最大灵活性。 2 5s p rin g 的核心机制i o c 与a o p i o c 模式与a o p 框架在s p r i n g 中占有着举足轻重的地位，是s p r i n g 框架的核 心部分。其中i o c 模式是贯穿s p r i n g 框架始终的一个概念【1 6 】，它秉承了o o f 模式 的基本理念，即：“针对接口编程，而不是实现”，在进入i o c 模式之前我们先介 绍与面向接口编程密不可分的另一设计模式一一工厂模式。 2 5 1 工厂模式 依据“针对接口编程”t 1 】的理念，具体的对象依赖与抽象接口，但是j a v a 语 言要求在将一个( 具体) 类实例化的时候，必须调用这个具体类的构造子，所以 j a v a 语言给出的实例化方法无法做到只依赖于抽象类型。工厂模式的设计正是用 来解决这个问题的，工厂模式专门负责将大量有共同接口的类实例化，工厂模式 可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。工厂模 式一般有以下几种形态【1 7 - 19 】： ( 1 ) 简单工厂模式：又称静态工厂模式。它是不同的工厂方法模式的一个特殊 实现，往往作为普通工厂模式的一个特例讨论。简单工厂模式是类的创建模式， 其一般性结构如下图所示： 图2 4 简单工厂模式 f i g 2 4s i m p l ef a c t o r yp a t t e r n 从上图可以看出，简单工厂模式涉及工厂角色、抽象产品以及具体产品角色 三个角色： 工厂类角色：担任这个角色的是工厂方法模式的核心，含有与应用紧密相 关的商业逻辑。工厂类在客户端的直接调用下创建产品对象，他往往有一个具体 j a v a 类来实现。 抽象产品角色：担任这个角色的类是由工厂方法模式所创建的对象的父 类，或它们共同拥有的接口。抽象产品角色可以用一个j a v a 接口或者j a v a 抽象 类实现。 具体产品角色：工厂方法模式所创建的人和对象都是这个角色的实例，具 体产品角色由一个具体j a v a 类来实现。 蒌 在简单工厂模式中，一个工厂类处于对产品类实例化的中心位置上，它知道 每一个产品，它决定哪一个产品类应该被实例化。这个模式的优点是允许客户端 相对独立于产品创建的过程，并且在系统引入新产品的时候无需修改客户端，但 是当有新的产品加入到系统中去，就需要修改工厂类，将必要的逻辑加入到工厂 类中。 ( 2 ) 工厂方法模式：又称多态性工厂模式或虚拟构造子模式。其理念是定义一 个创建产品对象的工厂接1 3 ，将实际创建工作推迟到子类中。工厂方法模式是简 单工厂模式的进一步抽象和推广。由于使用的多态性，工厂方法模式保持了简单 工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再 负责所有的产品的创建，而是将具体创建的工作交给子类去做。这个核心类成为 了一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一 个产品类应当被实例化这种细节。这种进一步抽象化的结果，使这种工厂方法模 式可以用来允许系统在不修改具体工厂角色的情况下引进新的产品，这一特点无 疑使得工厂模式具有超过简单工厂模式的优越性。 ( 3 ) 抽象工厂模式：又称工具箱模式。是所有形态的工厂模式中最为抽象和最 具一般性的一种形态。抽象工厂模式可以向客户端提供一个接口，使得客户端在 不必指定产品的具体类型的情况下，创建多个产品的产品对象，这就是工厂模式 的理念。 弄：垂一事 由上图可以看出，抽象工厂模式涉及以下的角色： 抽象工厂角色：担任这个角色的是工厂方法模式的核心，它是与应用系统 的商业逻辑无关的。通常使用j a v a 接口或者抽象j a v a 类实现，而所有的具体工 厂类必须实现这个j a v a 接口或继承这个抽象j a v a 类。 具体工厂角色：这个角色直接在客户端的调用下创建产品的实例。这个角 色含有选择合适的产品对象的逻辑，而这个逻辑是与应用系统的商业逻辑紧密相 关的。通常使用具体j a v a 类实现这个角色。 抽象产品角色：担任这个角色的类是工厂方法模式所创建的对象的父类， 或他们共同拥有的接口。通常使用j a v a 接口或者抽象j a v a 类来实现这一角色。 具体产品角色：抽象工厂模式所刨建的任何产品对象都是某一个具体产品 类的实例。这是客户端最终需要的东西，其内部一定充满了应用系统的商业逻辑。 通常使用具体j a v a 类实现这个角色。 应该看到随着需求的不断增加，实际的工厂类也会越来越复杂，子类的修改 越来越频繁，这样我们也不得不随时修改工厂类的代码，于是给系统的维护带来 了很大的压力，l o c 就是针对它的不足之处提出的一个工厂模式的升华和改进的设 计模式。 2 5 2l o c 模式简介 当我们进行项目开发时，我们将一个复杂的系统进行有效的划分，形成多个 模块，这样可以使我们有效的理解和控制整个系统，使每个模块都能易于理解和 维护。但是模块之间以某种方式进行信息交换的时候，模块和模块之间就不可避 免的发生了某种耦合关系。如果各个模块之间没有任何的关联，那么该模块不属 于此系统，或者整个软件不过是互不相干的系统的简单堆积，对每一个系统其所 有功能均在一个模块中实现，这等于没有做任何模块的分解。 从这种意义上说来，模块间的依赖关系是不可避免的。但是，如果模块间耦 合关系过强则会给我们带来很大的麻烦，对整个系统来说会造成很大的危害。特 别是当需求发生变化时，代码的维护将是一个灾难。因此，我们要尽可能的消解 模块间不必要的耦合，尽量提高系统的质量。 i o c ( i n v e r s i o no fc o n t r 0 1 ) 模式，即控制反转，就是为了耍解决模块间的 耦合，依赖注入( d e p e n d e n c yi n j e c t i o n ) 是对i o c 模式的种扩展的解释。i o c 是一种用来解决组件( 实际上也可以是简单的j a v a 类) 之间依赖关系、配置及生 命周期的设计模式，对组件依赖关系的处理是i o c 的精华部分。其中i o c 的实际 意义就是把组件之间的依赖关系提取( 反转) 出来，由容器来具体配置。这样， 各个组件之间就不存在h a r d c o d e 的关联，任何组件都可以最大程度的得到重用。 而运用了i o c 模式后，我们不再需要自己管理组件之间的依赖关系，只需要声明由 容器去实现这种依赖关系。就好像把对组件之间依赖关系的控制进行了倒置，不 再由组件自己来建立这种依赖关系丽交给容器去管理。 2 5 3i o c 的实现方式 i o c 的实现主要有接口注入、设值注入及构造子注入三种方式，其中接口注入 模式因为历史较为悠久，在灵活性、易用性上不如其他两种注入模式，因此在i o c 的专题世界内并不被看好，目前i o c 的实现方式主要以设值注入和构造子注入为 主。下边的例予说明了这两种方式的具体形式【2 。2 2 l 。 ( 1 ) 设值注入： p u b l i cc l a s sm y b u s i n e s s p r i v a t eaa ： p r i v a t ebb ； p r i v a t ev o i ds e t a ( aa ) t h i s a = a ： ) p r i v a t ev o i ds e t b ( bb ) t h i s b = b ： ) ( 2 ) 构造子注入 p u b l i cc l a s sm y b u s i n e s s p r i v a t eaa ； p r i v a t ebb ： p u b l i cm