（管理科学与工程专业论文）业务逻辑层模型的研究和应用.pdf

中文摘要 摘要 随着i n t e m e t 的日益普及，w e b 应用的复杂性不断地增加，其规模也在不断的 扩大，对于灵活性、可靠性和个性化都提出了更高的要求，这就给w e b 应用开发 带来了新的挑战。 在现有的w e b 开发中，m v c 模式对系统的界面表示、控制流程和业务逻辑进 行有效的隔离和封装提供了有益的思路，目前j 2 e e 平台上出现了许多基于m v c 模式的w e b 应用框架。但是基于m v c 模式的w e b 开发中，往往过多于关注对控 制流程、页面表示，而忽略了对业务逻辑模型的重用性的重视，造成业务逻辑模 型与实际设计模型的脱节这种开发方式违背了面向对象的原则，而这恰恰是大 多数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 t o n e - o n - o n ej 2 e e d e s i g n a n d d e v e l o p m e n t 一书，他倡导j 2 e e 实用主义的设计思想，并提供了一个初步的开发框架实现。在此基础之上，r o d j o h n s o n 进行了进一步的改造和扩充，使其发展为一个新的开发框架，即：s p r i n g 框架。s p r i n g 的i o c 与a o p 两大机制为大大降低了层次间的耦合，在业务逻辑层 上可以更多的关注于业务逻辑的设计。 本文对业务逻辑层模型中关键技术进行了研究，利用s p r i n g 为基础框架，结 合领域模型概念以及设计模式的思想，提出了业务逻辑层的设计方法，进而提高 了业务逻辑层的重用性和扩展性。在应用实践中，根据“面向接口”的原则，设 计并实施w e b 应用系统的开发，使其业务逻辑层的重用性和扩展性得到了极大的 提高。实践证明本文提出的基于业务逻辑层设计方法的w e b 应用框架，对应用系 统的开发具有非常重要的指导意义和实用价值。 关键词：s o t i n g 框架；领域模型；业务逻辑层：i o c l 0 p 英文摘要 t h er e s e a r c ha n d a p p l i c a t i o no nb u s i n e s st i e rm o d e l a b s t r a c t w i t ht h ei n t e r n e ! p o p u l a r i z i n g , t h ec o m p l i c a t i o no f 黜a p p l i c a t i o ni sc o n s t a n t l y i n c r e a s i n g ，a n di t ss c a l ei se n l a r g i n ga sw e l l i no r d e rt oc o n t e n tt h eh i g h e rr e q u e s tt ot h e f l e x i b i l i t y , r e l i a b i l i t ya n di n d i v i d u a t i o n , t h ew e ba p p l i c a t i o nf a c e st h en e wc h a l l e n g e i nn o w a d a yw e bd e v e l o p m e n t , m v cp a t t e r np r o v i d et h eb e n e f i c i a lt h o u g h tf o r s e p a r a t i n ga n de n c l o s i n gt h ei n t e r f a c ee x p r e s s i o n , c o n t r o l l i n gf l o wa n db u s i n e s sl o g i c r e s u l t i n g ，m a n yw e ba p p l i c a t i o nf r a m e w o r k sa p p e a r sb a s e do nj 2 e e h o w e v e r , m o s t w 曲d e v e l o p m e n tb a s e do nm v cp a t t e r nf o c u sc o n t r o l l i n gf l o wa n dp a g ee x p r e s s i o n m t h e rt h a nt h i n k i n gm u c ho ft h er e u s a b i l i t yo ft h eb u s i n e s sl o g i cm o d e l i tm a k e st h e d i s j o i no fb e t w e e nb u s i n e s sl o g i cm o d e la n dr e a ld e s i g nm o d e l t 1 1 i sd e v e l o pm o d e d i s o b e y st h eo b j e c t - o r i e n t e dp r i n c i p l e a n dm o s tw 曲d e v e l o p m e n th a v et h i sc o m m o n d e f e c t s oi t sh a r dt om a i n t a i na n de x p a n dt h es y s t e m ，n o te v e nt h es o r w a r er e u s i n g 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 tm o s t l yr o o t e d i nt h e b 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 m 埘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 瑚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 。i tp r o v i d e si o c c o n t a i n e ra n da o ps u p p o r t 协r e d u c et h ec o u p l i n gb e t w c c nt h et i e r ss ot h a tm o r e a t t e n t i o nc a nb ep a i do nd e s i g n i n gb u s i n e s s1 0 9 i co nb u s i n e s st i e r t h i sp a p e rr e s e a r c h e st h ek e r n e lt e c h n i q u eo fb u s i n e s st i e rm o d e l ，a n du t i l i z e st h e s p r m ga sb a s ef r a m e w o r k , w i t ht h ei d e o l o g yo fd o m a i nm o d e la n dd e s i g np a t t e r n ， p r o v i d e st h ed e s i g nm e t h o do fb u s i n e s st i e r a c c o r d i n g l y , r e u s a b i l i t ya n df l e x i b i l i t yo f b u s i n e s st i e rw i l lb ei m p r o v e di m m e n s e l y i np r a c t i c e 。t h ef x a m e w o r ki nt e r m so ft h e p 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 s a n da c t u a l i z e st h ed e v e l o p m e n to fw e b a 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 f b u s i n e s sl a y e r i tp r o v e dt h a td e s i g n m e t h o do fb u s i n e s st i e rh 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 dp r a c t i c a lv a l u ef o r t h ed e v e l o p m e n to f a p p l i c a t i o ns y g e m s k e yw o r d s ：s p r i n gf r a m e w o r k = d o m a i nm o d e l ；b u s i n e s st i e r ；i o c ；a o p 大连海事大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：本论文是在导师的指导下，独立进行研究工作所取得的成果， 撰写成硕士学位论文：些釜逻担屋搓型鲍班窟塑廛旦：。除论文中已经注明引用的内 容外，对论文的研究做出重要贡献的个人和集体，均己在文中以明确方式标明。 本论文中不包含任何未加明确注明的其他个人或集体已经公开发表或未公开发表 轳蚴游就蟀膈担矗名谚艮似“日 论文作者签名：虎啪年乡月以日 学位论文版权使用授权书 本学位论文作者及指导教师完全了解“大连海事大学研究生学位论文提交、 版权使用管理办法”，同意大连海事大学保留并向国家有关部门或机构送交学位论 文的复印件和电子版，允许论文被查阅和借阅。本人授权大连海事大学可以将本 学位论文的全部或部分内容编入有关数据库进行检索，也可采用影印、缩印或扫 描等复制手段保存和汇编学位论文。 保密口，在年解密后适用本授权书。 本学位论文属于： 保密口 不保密i ( 请在以上方框内打“”) 一a 淋一名： 日期：枷年 月日 业务逻辑层模型的研究和应用 第1 章绪论 1 1 课题背景 随着当今互联网技术的迅速发展和普及，其产生的影响不仅仅是对个人，而 且对于整个社会的企业和政府部门等都提出更高的要求。社会各个领域的企业都 在努力进行着企业网络信息化，建立企业应用系统以实现信息资源的管理和共享。 因此，对现代企业而言，建立一个基于互联网的、灵活的、易扩展和易维护的企 业信息系统是企业自身壮大，适应市场发展需求的必然选择。 为了满足用户的需求，适应激烈的市场竞争，各种w e b 应用系统必须不断地 改进其内容和形式。框架就是一组协同工作的类，它们为特定类型的软件构筑了 一个可重用的设计1 1 1 。软件系统的架构设计决定着软件产品的生死存亡，良好的开 端相当于成功的一半，因此选择正确合理的系统体系结构是关键【2 】。j 2 e e ( j a v a 2 e n t e r p r i s ee d i t i o n ) ，实际上是书面上的一种规范和标准，而在实际的企业开发项目 中j 2 e e 又成为了开发人员所遵循的一个框架。它将开发的系统分为多个“层”， 而每层又有着自己的框架 3 1 。w e b 应用系统b s 模型的三层或多层框架结构基本是 基于j 2 e e 的层次结构，一般系统分为表示层、业务逻辑层、数据层。更关键的是 由于j a v a 虚拟机的跨平台性，使得基于j 2 e e 的w e b 框架可以在不同的操作系统 下运行，增加了它的可移植性和重用性【4 】。现今流行的w e b 框架多基于m v c 模式， 然而m v c 模式仅仅为w 曲应用提供了对应的设计方法，并没有提供具体的技术 实现，为此产生了众多的w e b 应用开发框架，它们大多使用m v c 模式作为指导 思想，各自定义不同的规范，提供不同的技术细节，以便使w e b 开发更为有效快 捷。 虽然w e b 应用框架能够给应用提供良好的结构，使得人们无需再想方设法解 决些经典的问题，而且系统的架构更统一、更容易理解，但大多w e b 应用框架 集中在解决表示层的问题上，对于业务逻辑层的设计没有提供更多的支持，并不 能根本解决层次藕合紧密、程序复用度低的问题。因此，对于w e b 应用开发的业 务逻辑层的设计对于项目的成功往往起到了很关键的作用。 第1 章绪论 1 2 课题的来源和意义 现今流行的w e b 框架多基于m v c 模式，可以降低在表示层上的复杂度，而 在业务逻辑层上的支持还不是很完善，这也是由于业务是系统的主体，框架只是 一个工具，荐好的框架也是为业务应用服务的，而不是设计业务的。所以业务逻 辑层的设计在这个系统架构的设计中是占有主导地位的，现今的w e b 应用开发往 往忽略了这一点，只是为了实现应用业务而设计。这就造成了业务逻辑层的不易 维护，难于扩展，甚至最后使整个系统开发陷入困境。 笔者在攻读学位期间参与了多个企业或物流信息系统的设计与开发，在实践 的基础上对于信息系统的架构设计积累了一定的经验，因此对于业务逻辑层设计 的重要性深有体会，本着实用的原则，在基于j 2 e e 的业务逻辑层的设计方面进行 了深入的研究，试图解决在开发中遇到的业务逻辑层设计的普遍问题。 领域模型概念就是针对系统开发的可重用的需求而提出的。可重用的说明、 可重用的体系结构、面向领域的可重用构件在系统中也得到不断积累，生成目标 系统时即可重用。当然，相同领域中系统中的各个具体系统允许存在差异，但关 心的是它们的共性。通过建立其特定应用领域的领域模型，当开发这类系统或修 改原系统中的一个目标系统时，就可以通过裁剪领域模型来实现，这就达到大规 模软件重用、提高软件开发效率和系统可靠性的目的。与纯构件方法相比，构件 方法只重用砖头，即注重功能模块的设计与实现，而领域模型方法不但重用砖头、 更要重用框架。在系统族中共性比较多的时候，重用所获得的效益也更加明显御。 本文结合了某物流管理系统，提出领域中的业务逻辑层的设计方案，利用 s p r i n g 框架为基础实现整个框架。本文的意义在于结合领域模型的概念，设计业务 逻辑层设计模型，从而可以最大的实现业务模型的抽象，以改进传统业务逻辑层 设计带来的难以扩展，不易维护等弊端。而且利用s p r i n g 框架的i o c 机制最大程 度地降低各个层次间的耦合度，构建出一个强健的整体框架模型。 1 3 课题研究的主要内容及论文的组织 第一章：主要介绍了课题的背景及本论文的研究目的和意义。 第二章；简介m v c 模式与s p r i n g 框架，包括m v c 模式的理念，m v c 模式 的发展以及它的优缺点。同时简要介绍了s p r i n g 框架的基本构成，以及它对m v c 2 业务逻辑层模型的研究和应用 模式的实现和s p r i n g 框架的核心内容，其中s p r m g 框架的核心内容包括：i o c ( 控 制反转) 模式和a o p ( 面向方面编程) 。 第三章；提出基于领域的业务逻辑层设计方法。改进传统的业务逻辑层设计 方法，利用s p r i n g 实现框架间的整合。包括简要介绍领域模型的概念，比较传统 业务逻辑层设计方法和改进后的设计方法，给出业务逻辑层整体设计方案和层次 间的整合方案，以及相应的技术细节。 第四章：使用改进的业务逻辑层设计方法来指导实际系统的实现。包括对实 际系统的分析、设计，及使用整合框架完成系统的实现。验证整合框架在实践中 的意义，同时验证以此框架完成的系统在业务层所具有的可扩展性。 第五章；分析评价 第六章：总结与展望。 3 第2 章s p r i n g 应用开发框架 2 1j 2 e e 体系框架 第2 章s p ri n g 应用开发框架 2 1 1 吖c 模式简介 m v c 模式是由t r y g v er e e n s k a u g 教授提出的，首先被应用在s m a u t a l k - 8 0 环 境中网。m v c 英文即m o d e l - v i e w - c o n t r o l l e r ，它是目前非常流行的一种软件设计 模式。早在7 0 年代，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 l 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 1 所示。 图2 1 m v c 模式 f i g 2 1m v cp a t t e m 4 业务逻辑层模型的研究和应用 视图( v i e w ) ：代表用户交互界面，对于w e b 应用来说，可以概括为h 蹦l 界面，但有可能为x h t m l 、x m l 和a p p l e t 。随着应用的复杂化和规模的增加， 界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，m v c 设计模式 对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在 视图上的业务流程的处理。业务流程的处理交予模型( m o d e l ) 处理。比如一个订 单的视图只接受来自模型的数据并显示给用户。以及将用户界面的输入数据和请 求传递给控制和模型。 模型( m o d e l ) ：就是业务流程状态的处理以及业务规则的制定。业务流程的 处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处 理结果。业务模型的设计可以说是m v c 最主要的核心。目前流行的e j b 模型就 是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以 便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这 种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者 来说，就可以专注于业务模型的设计。m v c 设计模式告诉我们，把应用的模型按 一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计 依据。抽象与具体不能隔得太远，也不能太近。m v c 并没有提供模型的设计方法， 而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性可以用对 象编程来做比喻，m v c 定义了一个顶级类，告诉它的子类你只能做这些，但没法 限制你能做这些。这点对编程的开发人员非常重要。 业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象 的数据保存( 持续化) 比如将一张订单保存到数据库，从数据库获取订单。可以 将这个模型单独列出，所有有关数据库的操作只限制在该模型中。 控制( c o n t r o l l e r ) ：可以理解为从用户接收请求，将模型与视图匹配在一起， 共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一 个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。 控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后， 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合 要求的视图返回给用户因此，一个模型可能对应多个视图，一个视图可能对应 多个模型 7 - 1 3 1 。 第2 章s p h n g 应用开发框架 2 i 2 流行j 2 e e 框架 对于应用开发来说，降低开发成本、缩短开发周期、提高可维护性和运行效 率是其追求的目标。对于w e b 开发来说也不例外。j 2 e e 平台的出现在一定程度上 减少了w e b 应用开发的成本和复杂度，但是其本身过于复杂的体系结构、难预测、 开发和维护成本的高昂，使得j 2 e e 的架构方案常常无法让人满意。为此，现在许 多的w e b 应用框架提供了更为便捷的方案，目前较为流行的框架有很多，这里只 列举其中的几个框架作为参考： s t r u t s 框架【1 4 】：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 曲层的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 框架【1 5 】：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 bc o m p o n e n t 。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 框架【1 6 1 ：t u r b i n e 是由a p a c h ej a k a r t a 开源开发小组提供的服务器端j a v a w 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 tk 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 。数据层 6 业务逻辑层模型的研究和应用 采用的是t o r q u e 和p e e r s ，利用x m l 技术将关系型数据库和j a v ac 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 就有被边缘化的危险；其次它的导航性比较差，页面管理有一些凌乱。 2 2s p r ；n g 框架简介 在进入具体的细节之前，先整体的了解一下s p r i n g 框架，包括它的来历、出 发点、以及其基本的构成。 2 。2 。1s p r i n 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 介绍他自己的 f f 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 7 1 。 在s p r i n g 之前，许多专用框架在各个领域都有着很多出色的解决方案，比如： w e b 框架、持久化方案、远程调用工具等等，然而将这些工具整合成一个全面的架 构困难重重，甚至成为一种负担。s p r i n g 的目标是提供一种贯穿始终的解决方案， 将各种专用框架整合成一个连贯的整体构架。从这种意义上说，s p r i n g 框架就像一 个黏合剂，将各个领域出色的解决方案黏合到一起，构成一个新的架构，更好的 为应用服务n 8 1 。 s p r i n g 力求不强加任何架构风格，而是把选择的权利留给开发者，允许用户使 用其中的单项功能，而不是把整个框架强加给用户。也就是说，s p r i n g 并不是一个 全有或全无的解决方案，用户可以根据自己的实际需求来灵活的选择s p r i n g 中的 各部分。s p r i n g 中的许多特性，如：j d b c 抽象层或者h i b e r n a t i o n 集成，都可以作 为一个库单独使用，当然也可以作为s p r i n g 整体方案的一个部分。从这里可以看 出，s p r i n g 提供了极大的灵活性，即可以选择不同领域优秀的工具，又可以选择 s p r i n g 本身的各个部分。下面来看一下s p r i n g 的基本结构。 7 第2 章s p r i n g 应用开发框架 2 2 2s p r i n g 框架的基本结构 图2 2 所示为s p r i n g 框架的基本结构图： 图2 2s p r i n g 框架的基本结构 f 培2 , 2b a s i cs t n l c l u r co f s p r i n gf r a m e w o r k 由图2 2 中所示s p r i n g 框架有7 个基本模块，这7 个模块是相互独立的，每个 模块都有一个对应的j a t 文件。其中【1 9 】： 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 m gd a o ：提供y d b c 的抽象层，使得开发者不用去编写非业务功能的j d b c 代码，同时提供它同时能够提供编程方式和声明方式控制事务。 s p r i n go r m ：为当前流行的o r m 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 2 3s 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 眈1 】： ( 1 ) 将w e b 页面中的输入元素封装为一个( 请求) 数据对象。 c 2 ) 根据请求的不同，调度相应的逻辑处理单元，并将( 请求) 数据对象作为 参数传入。 ( 3 ) 逻辑处理单元完成运算后，返回一个结果数据对象。 ( 4 ) 将结果数据对象中的数据与预先设计的表现层相融合并展现给用户。 各个m v 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 将请求分发到不同 的处理器，框架还包括可配置的处理器映射，视图解析，本地化，主题解析，支 持文件上传等等，其具体的类如图2 3 所示： 图2 3 s p r i n g 的w e b 实现模式 f i g 2 3s p r i n g sw e bi m p l e m e n tp a t t e r n 控制器：缺省的处理器是一个简单的控制器( c o n t r o l l e r ) 接口，这个接口仅 仅定义了m o d e l a n d v i e wh a n d l e r e q u e s t ( r e q u e s t , r e s p o n s e ) 方法。可以实现这个接口 生成应用的控制器，但是使用s p r i n g 提供的一系列控制器实现会更好一些，比如 a b s t r a c t c o m m a n d c o n t r o l l e r 和s i m p l c f o r m c o n t r o l l e r 。在实际的应用中控制器一般 都从它们继承。 9 第2 章s p r i n g 应用开发框架 视图；s p r i n g 的视图解析相当灵活。一个控制器实现甚至可以直接输出一个视 图作为响应，这需要使用n u l l 返回m o d e l a n d v i e w 。在一般的情况下，s p r i n g 使用 一个m o d e l a n d v i e w 实例包含视图名字和模型映射表，模型映射表提供了b e a n 的 名字及其对象( 比如命令对象或表单对象，引用数据等等) 的对应关系。视图名 解析的配置是非常灵活的，可以通过b e a n 的名字，属性文件或者你自己的 v i e w r e s o l v e r 来实现。抽象的模型映射表完全抽象了表现层，没有任何限制：j s p ， v e l o c i t y ，或者其它的技术任何表现层都可以直接和s p r i n g 集成。模型映射表 仅仅将数据转换成合适的格式，比如j s p 请求属性或者v e l o c i t y 模版模型等。 模型：对于模型部件，s p r i n g 提供了一个i o c 容器，使用它可以将各个类进行 组装，它全权负责依赖查询，受管对象只需暴露j a v a b e a n 的s e t t e r 方法或者带参 数的构造予，让容器可以在初始化时组装对象的依赖关系。这样i o c 容器负责查 找组件需要的资源，并将必要的资源注入到业务对象中。于是，只要对容器重新 配置，有不同的方式获得资源，就可以让组件获得不同的资源，面不必修改代码。 2 2 4s p r i n gm v c 框架的特点 s p r i t l g 框架所提供的m v c 有着以下的一些特点 2 2 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 ) 可定制的处理器映射，可定制的视图解析：灵活的模型可以根据名字值 1 0 业务逻辑层模型的研究和应用 映射，处理器映射和视图解析使应用策略从简单过渡到复杂，而不是只有一种单 一的方法。 可定制的本地化和主题解析，支持j 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 3s p r i n g 的核心机制l 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 框架始终的一个概念圈，它秉承了g o f 模式 的基本理念，即：“针对接口编程，而不是实现”，在进入i o c 模式之前先介绍与 面向接口编程密不可分的另_ 设计模式工厂模式。 2 3 1 工厂模式 依据“针对接口编程”】的理念，具体的对象依赖于抽象接口，但是j a v a 语 言要求在将一个( 具体) 类实例化的时候，必须调用这个具体类的构造子，所以 j a v a 语言给出的实例化方法无法做到只依赖于抽象类型。工厂模式的设计正是用 来解决这个问题的，工厂模式专门负责将大量有共同接口的类实例化，工厂模式 可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。工厂模 式一般有以下几种形态 2 4 - 2 6 1 ： 1 简单工厂模式：又称静态工厂模式。它是不同的工厂方法模式的一个特殊 实现，往往作为普通工厂模式的一个特例讨论。简单工厂模式时类的创建模式， 其一般性结构如图2 4 所示： 图2 4 简单工厂模式 f i g 2 4s i m p l ef a c t o r yp a t t e r n 从图2 4 可以看出，简单工厂模式涉及工厂角色、抽象产品以及具体产品角色 第2 章s p r i n g 应用开发框架 三个角色： 工厂类角色：担任这个角色的是工厂方法模式的核心，含有与应用紧密相关 的商业逻辑。工厂类在客户端的直接调用下创建产品对象，他往往由一个具体j a v a 类来实现。 抽象产品角色：担任这个角色的类是由工厂方法模式所创建的对象的父类， 或它们共同拥有的接口。抽象产品角色可以用一个j a v a 接1 3 或者j a v a 抽象类实现。 具体产品角色：工厂方法模式所创建的人和对象都是这个角色的实例，具体 产品角色由一个具体j a v a 类来实现。 在简单工厂模式中，一个工厂类处于对产品类实例化的中心位置上，它知道 每一个产品，它决定哪一个产品类应该被实例化。这个模式的优点是允许客户端 相对独立于产品创建的过程，并且在系统引入新产品的时候无需修改客户端，但 是当有新的产品进入到系统中去，就需要修改工厂类，将必要的逻辑加入到工厂 类中。 2 工厂方法模式：又称多态性工厂模式或虚拟构造子模式。其理念是定义一 个创建产品对象的工厂接口，将实际创建工作推迟到子类中。工厂方法模式是简 单工厂模式的进一步抽象和推广。由于使用的多态性，工厂方法模式保持了简单 工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再 负责所有的产品的创建，而是将具体创建的工作交给子类去做。这个核心类成为 一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪个 产品类应当被实例化这种细节。这种进一步抽象化的结果，使这种工厂方法模式 可以用来允许系统在不修改具体工厂角色的情况下引进新的产品，这一特点无疑 使得工厂模式具有超过简单工厂模式的优越性。 3 抽象工厂模式：又称工具箱模式。是所有形态的工厂模式中最为抽象和最 具一般性的一种形态。抽象工厂模式可以向客户端提供一个接口，使得客户端在 不必指定产品的具体类型的情况下，创建多个产品族种的产品对象，这就是工厂 模式的理念。 1 2 业务逻辑层模型的研究和应用 甲：甲甲 唪i 本嚎两薛最 l ：一； 图2 5 抽象工厂模式 f i g 2 5a b s t r a c tf a c t o r yp a t t e r n 由图2 5 可以看出，抽象工厂模式涉及一下的角色： 抽象工厂角色：担任这个角色的是工厂方法模式的核心，它是与应用系统的 商业逻辑无关的。通常使用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 类实现这个角色。 应该看到随着需求的不断增加，实际的工厂类也会越来越复杂，子类的修改 越来越频繁，这样也不得不随时修改工厂类的代码，于是给系统的维护带来了很 大的压力，i o c 就是针对它的不足之处提出的一个工厂模式的升华和改进的设计模 式。 2 3 2l o c 模式简介 当进行项目开发时，将一个复杂的系统进行有效的划分，形成多个模块，这 样可以有效的理解和控制整个系统，使每个模块都能易于理解和维护。但是模块 之间以某种方式进行信息交换的时候，模块和模块之间就不可避免的发生了某种 耦合关系。如果各个模块之间没有任何的关联，那么该模块不属于此系统，或者 整个软件不过是互不相干的系统的简单堆积，对每一个系统其所有功能均在一个 第2 章s p r i n g 应用开发框架 模块中实现，这等于没有做任何模块的分解。 从这种意义上说来，模块间的依赖关系是不可避免的。但是，如果模块间耦 合关系过强则会带来很大的麻烦，对整个系统来说会造成很大的危害。特别是当 需求发生变化时，代码的维护将是一个灾难。因此，要尽可能的消解模块间不必 要的耦合，尽量提高系统的质量。 s p r i n g 框架的核心基于“控制反转( i n v e r s i o no f c o n t r o l ，i o c ) ”原理。i o c 是 一种将组件依赖关系的创建和管理置于程序外部的技术。依赖注入( d e p e n d e n c y i n j e c t i o n ，d i ) 是对i o c 模式的一种扩展的解释网。 s p r i n g 的i o c 或d i 模式的实现方式是基于两个j a v a 核心概念：j a v a b e a n 和 i n t e r f a c e 。当使用d i 的时候，可以使得依赖配置与你的代码保持隔离。j a v a b e a a 提供了一种创建j a v a 资源的标准方法，并且这些资源是可以通过标准方式配置的。 接口与d i 是相互受益的技术。通过采用d i ，为基于接口的设计而编写的辅助代码 大大减少了，近乎于零。反过来，通过采用接口，你可以获得d i 的最大好处，因 为b e a u 可以采用任何满足其依赖的接口实现。 在d i 的语境中s p r i n g 运作得更像是一个容器，而非框架一为应用程序的类 提供所有所需要的实例，但不会像在e j b 中创建持久化e n t i t yb e a n 那样富有侵略 性 2 3 3i o c 的实现方式 i o c 的实现主要有接口注入、设值注入及构造子注入三种方式，其中接口注入 模式因为历史较为悠久，在灵活性、易用性上不如其他两种注入模式，因此在i o c 的专题世界内并不被看好，目前i o c 的实现方式主要以设值注入和构造子