（控制理论与控制工程专业论文）基于struts框架的养老保险管理系统设计和实现.pdf

摘要 y 9 3 n 1 二7 传统的基于客户机服务器( c l i e n t s e r v e r ，c l s ) 体系结构的养老保险管理系统 的更新和维护的工作很困难，并且由于数据管理分散，存在于不同的点上的重复信 息有可能会导致信息数据的不一致，使经办效率和服务质量有所下降。 因此，本文采用基于浏览器服务器( b r o w s e r s e r v e r ，b s ) 结构的w e b 应用系 统将传统的c s 体系结构的应用分解开来，构成由一个由数据库服务器和多个w e b 应用服务器组成的多层体系结构，采用这种体系结构，不仅有利于对系统进行更新 和维护，也方便养老保险经办机构对数据进行集中管理，提高经办效率和服务质量， 系统的管理也变的相对方便。 本论文对养老保险业务特点和功能需求进行分析后，选择了j 2 e e 平台的m v c 模式的s t r u t s 框架来开发一套养老保险管理系统；在研究了基于m v c 模式的 s t r u t s 框架的工作原理和实现机制后，应用s t r u t s 框架开发养老保险管理系统中 的参保人信息管理的子系统。针对占系统很大比例的数据的增、删、查、改操作中 抽象出了一个数据操作通用框架，此框架是使用数据访问对象( d a t aa c c e s s o b j e c t ，d a o ) 模式设计的。d a o 模式的作用是将底层数据访问操作与高层业务逻辑 分离，对上层提供面向对象的数据访问接口，从而实现了业务核心和具体数据源的 解耦。 通过实践证明s t r u t s 框架层次清晰，页面导航便利的特点，可以实现系统的 快速开发和灵活配置，并达到较高的可靠性、可扩展性及模块的重用性，而且系统 的用户界面风格统一和直观。 关键 司：b s 模式、j 2 e e 、m v c 模式、s t r u t s 框架、d a o 设计模式、养老保险 e n d o w m e n ti n s u r a n c em a n a g e m e n t s y s t e m sd e s i g n a n di m p l e m e n t a t i o nb a s e do ns t r u t sf r a m e w o r k a b s t r a c t n et r a d i t i o n a lm a n a g e m e n ts y s t e mo fe n d o w m e n ti n s u r a n c 圮w h i c hb a s e do nt h e c l i e n t s e r v e r ( c s ) a r c h i t e c t u r ei sd i f f i c u l tt ou p d a t ea n dm a i n t a i nt h es y s t e m a tt h es a m e t i m e ，o na c c o u n to f t h ed i s p e r s i v em a n a g e m e n to f d a t a , r e d u p l i c a t ei n f o r m a t i o nl o c a t e di n d i f f e r e n tn o d e sm d u st h ev a r i a n c eo fi n f o r m a t i o nd a t a , w h i c hm a k e st h ee f f i c i e n c yo f w o r ka n dt h eq u a l i t yo fs e r v i c em a r k e d l yd e c l i n e a c c o r d i n g l y , t h i sp a p e rw h i c ht a k e t h ew 曲a p p l i c a t i o n s y s t e mb a s e do n b r o w s e r s e r v e rf w s ) a r c h i t e c t u r ed i v i d e dt h ea p p l i c a t i o no ft h et r a d i t i o n a lc s a r c h i t e c t u r ea n ds t r u c t u r e dam a l t i l a y e ra r c h i t e c t u r em a d eu po fd a t a & e r v e fa n dm a n y w e ba p p l i c a t i o ns e r v e r s n ew a yt ot a k e nt h i sk i n do fs y s t e ma r c h i t e c t u r em a k e si t c o n v e n i e n tn o t o n l y t o u p d a t ea n dm a i n t a i ns y s t e mb u ta l s ot om a n a g ed a t a c e n t r a l l y ，i m p r o v e st h ee f f i c i e n c yo fw o r ka n dt h eq u a l i t yo fs e r v i c e ，a n da l s om a d et h e m a n a g e m e n tc o m p a r a t i v e l yc o n v e n i e n t a f t e ra n a l y z i n gt h eo p e r a t i o n sc h a r a c t e r i s t i ca n dt h ef u n c t j 彻i sr e q u i r e m e n to f e n d o w m e n ti n s u r a n c eb u s i n e s s ，t h em a n a g e m e n ts y s t e mo fe n d o w m e n ti n s u r a n c e c h o o s e ss t r u t sh 薯m e w o r ko fm v c p a t t e r n , w h i c hb a s e do nj 2 e ea r c h i t e c t u r e ，t od e v e l o p t h es y s t e m a f t e rr e s e a r c h i n 窑t h ew o r kp r i n c i p l ea n dt h em e c h a n i s mo fr e a l i z a t i o nw h i c h b a s e do nt h em v cp a t t e r oo fs t r u t sf r a m e w o r k , t h ea u t h o rd e v e l o pt h ei n f o r m a t i o n m a n a g e m e n ts u b s y s t e mo fi n s u r a n ti nt h em o d e l o fm a n a g ei n s u r a n c e si n f o r m a t i o n a c c o r d i n gt ot h eh i g h e rp e r c e n t a g eo ft h ed a t ai nt h es y s t e m ，ad a t ao p e r a t i o nc o m m o n f r a m e w o r k ，w h i c hd e v i s e dw i t hd a o ( d a t aa c c e s so b j e c t ) p a t t e r n , w a sa b s t r a c t e df r o m t h ea d d i t i o n ，d e l e t i o n ，m o d i f i c a t i o n , q u e r yo p e r a t i o n s 田地f u n c t i o no ft h ed a o p a t t e mi s t od i v i d e dv i s i t a t i o no ft h el o w - l a y e rf r o mb u s i n e s sl o g l c ao ft h eu p - l a y e r ，s u p p l yd a t a v i s i t e di n t e r f a c eo fo b j e c to r i e n t e df o ru p - l a y e r , a n dr e a l i z e dt h ed c c o n p l eb e t w e e n b u s i n e s sc o r ea n dm a t e r i a ls o u r c ed a t a p r a c t i c ep r o v et h a ts t r u t sf r a m eo w nt h ec h a r a c t e r so fc l e a rl a y e r sa n dc o n v e n i e n t p a g en a v i g a t i o n ，h a v e t h ef u n c t i o nt or e a l i z e q u i c kd e v e l o p m e n ta n d f l e x i b l e c o n f i g u r a t i o n ，h a v eh i g h e rr e l i a b i l i t y , e x p a n s i b i l i t ya n dr e u s eo fm o d u l e sa n dh a v eu n i t i v e a n di n t u i t i o n i s t i cu s e ri n t e r f a c e i i i n a m e ：w a n gw u ( m a j o r i nc o n t r o lt h e o r ya n de n g i n e e r i n g ) d i r e c t e db ya s s o c i a t ep r o f e s s o rc a ig u i z h o u k e yw o r d s ：b sa r c h i t e c t u r e ，j 2 e e , m v cp a t t e r n ，s t r u t sf r a m e w o r k , d a t a a c c e s so b j e c t ( d a o ) p a t t e r n ，e n d o w m e n ti n s u r a n c e i v 第一章引言 1 引言 1 1 课题的研究背景 传统的c s 体系结构的管理信息系统需要针对不同的操作系统开发不同版本的 软件，造成产品的更新换代十分频繁，高代价和低效率越来越不适应现代实际工作 的需要。目前遂宁市的养老保险管理系统是c s 体系结构的管理信息系统，它也存 在上述的问题m 。 网络时代的到来，不仅改变着人们的思维方式也改变着人们的生活方式。目前 应用系统的开发面临巨大的挑战：一方面，应用系统面对的是一个异构的分布式环 境，它必须支持与已有系统的集成性和与其他系统的互操作性；另方面应用系统 还必须具有高可用性、安全性、可靠性和伸缩性。在j a v a 这样的个强大的跨平 台面向对象语言出现之后，b s 体系结构猛烈她冲击着c s 体系结构，大有取而代 之的趋势“”。基于多层b s 体系结构的j 2 e e ( j a v a2p l a t f o r me n t e r p r i n s e e d i t i o n ) 平台作为一种建立企业应用的标准平台出现，并逐步成熟，得以飞速发展 “”。j 2 e e 平台使用了大量不同的技术标准如j a v as e r v e rp a g e s ( j s p ) ，j a v as e r v l e t ， e n t e r p r i n s ej a v a b e a n s ( e f f b ) 等，提供了多层分布式应用模型、组件复用能力、统 一的安全模型和灵活的事务处理，为开发和配置企业应用提供了健壮和稳定的服务。 j 2 e e 技术使得多层w e b 体系结构得到迅猛发展并逐渐成熟起来。可是，开发 企业级大型w e b 应用程序时，采用传统的m o d e l1 ，不仅开发效率低下、质量难以 保证并且对w e b 应用程序后期的测试和维护工作也变得十分困难。m o d e l1 的体系 结构中，j s p 页面完全负责接收客户蛹的请求与处理工作，并为客户端选择下一个 j s p 页面。m o d e l2 体系结构将w e b 应用程序的职责分解开来o ”，并且将程序控制 交给了j a v as e r v l e t 处理。这样，w e b 应用程序的不同组件具有了清晰、明确的职 责，不但提高了程序的可重用性，而且使得应用程序的开发和维护工作变得非常的 容易。m o d e l2 的这种分解方式通常被称为模型一视图一控制器( m o d e l - v i e w c o n t r o l l e r 。m v c ) 模式“1 。 s t r u t s 框架是基于j 2 e e 平台下在w e b 应用上实现的m v c 模式的框架，它将应 用程序分为模型、视图、控制器三个部分进行软件架构。s t r u t s 用j a v ab e a n s 实 现模型功能、用j s p 和f o r m b e a n s 实现视图功能、用j a v as e r v l e t 实现控制器功 能，向开发人员提供了统一的体系结构，并以此为基础，快速构建i n t e r n e tw e b 应用程序。s t r u t s 框架的应用，使开发人员可以集中精力关注构建业务应用层的工 作，而不必顾虑体系结构的问题。 第一章引言 1 2 研究的目的及所做的主要工作 本文通过对养老保险的业务特点和功能需求的分析，决定采用s u n 公司的3 2 e e 平台来开发养老保险管理系统。目前遂宁市的养老保险管理系统是用p o w e r b u i l d e r 设计的一个典型的c s 体系结构的应用程序，系统的表示逻辑和业务逻辑要在各个 客户端上独立运行，服务器只是一个原始数据的存储载体：而且采用面向过程的编 码方式，没有形成好的管理、服务和监督机制，存在着信息孤岛；存在于不同点上 的重复信息，导致经办效率和服务服务质量的降低，甚至有可能造成管理决策上的 失误；随着操作系统的不断升级换代，安装和升级应用程序时需要把软件安装到每 个客户机上，这样使得对该系统的更新和维护成本增加啪1 。 有鉴于此，作者在原有系统的功能基础之上，采用j 2 e e 平台将其重新设计为一 个基于e s 体系结构的w e b 应用，使用可移植性强、面向对象的j a v a 语言作为开 发工具，应用s t r u t s 框架作为w e b 层的体系结构跚，快速高效的建立一套具有平 台异构、方便维护、数据集中管理等优点的养老保险管理系统。利用测览器这一标 准的工具软件作为用户和系统的接口，应用程序的表示逻辑和业务逻辑均在服务器 端实现，从而消除了应用程序在客户端安装与维护的代价。同时，依托于j 2 e e 应用 服务器的功能支持，系统的性能更加稳定、可靠，这对原系统是一个有力的改进。 本文主要完成以下工作： 首先对框架和设计模式的作用进行了说明，概要说明j 2 髓平台的体系结构及 其优越性。通过深入剖析i i v c 模式的优势和设计思想，体现基于m v c 模式的s t r u t s 框架能够胜任高效高质量开发w e b 应用程序的工作需要，结合养老保险的业务特点 和功能需求，通过建立基予s t r u t s 框架的且具有四层体系结构的养老保险保险管理 系统的过程。充分论证使用s t r u t s 框架开发应用程序，的确能够提高开发速度，并 帮助我们交付高品质的软件。本文的最后就当前s t r u t s 的发展状况，介绍了养老保 险管理系统进步的开发工作，并指出在使用s t r u t s 框架构建养老保险管理系统 w e b 应用的过程中，所应注意的问题。而本文的重点是如何基于s t r u t s 框架实现对 w e b 层的开发。 总的来说，本文主要完成以下工作：作者详细设计养老保险管理系统中参保人 信息管理模块，并对基于j 2 e e 平台的耳e b 应用的领域知识探索之后，对s t r u t s 框 架的体系结构和采用的w c 模式做了深入的研究和全面的实践，并用强大的j a v a 跨平台面向对象语言作为开发上具实现参保人信息管理模块编码上作。在业务层采 用了数据访问对象( d a o ) 模式将数据持久化到数据库的通用模块，同时为了保证系 统在业务处理时有较高的效率，在w e b 服务器上采用t o m c a t 数据库连接池，来优化 响应速度，以力求系统的性能优良。 第一章引言 1 3 本论文的组织 第一章是绪论，介绍了课题的研究背景、研究目的及所做的主要工作和论文的 组织结构。 第二章探讨了设计模式和框架技术的特点，并指出了两者之间的关系；运用图 文的形式解释了w e 模式开发w e b 系统的的两种主要模式艟o d e l1 和m o d e l2 最 后对s u n 公司提供的企业解决方案j 2 e e 多层应用体系进行了介绍； 第三章，介绍了s t r u t s 框架，探讨了s t r u t s 框架各个组成部分的体系结构、 s t r u t s 框架的工作原理、组件及其配置文件； 第四、五章是本论文的核心，首先对养老保险系统的业务进行了概述，给出了 系统的功能设计、数据库设计和系统软件的体系结构；其次详细设计了系统中参保 人信息管理模块的视图、控制器和业务组件及其相应的配置文件，最后在业务层设 计了数据持久化通用模块，使用j 2 e e 的核心设计模式d a o 模式来实现。 第六章结束语对全文做了总结，提出了论文的不足之处及作者在开发养老保险 管理系统中的体会。 第二章框架和设计模式 2 框架和设计模式 2 1 框架 2 1 1 框架的概念“” 框架( f r a s e w o r k ) 是整个或部分系统的可重用设计，表现为一组抽象构件及构 件实例间交互的方法；另一种定义认为，框架是可被应用开发者定制的应用骨架。 前者是从应用方面、而后者是从日的方面给出的定义。 可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明 了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类 以及其实僦之间协作的方法，它为构件复用提供了上下文关系。因此构件库的大规 模重用也需要框架。 构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、 软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常 以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架 内对象间的交互模式和控制流模式。 框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协 作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激 活操作提供了标准的方法。 应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实现 了某应用领域通用完备功能( 除去特殊应用的部分) 的底层服务。使用这种框架的编 程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所 有应用期望的默认行为的类集合。具体的应用通过重写子类( 该子类属于框架的默认 行为) 或组装对象来支持应用专用的行为。 应用框架强调的是软件的设计重用性和系统的可扩充性，以缩短大型应用软件 系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较，应 用框架更注重于面向专业领域的软件重用。应用框架具有领域相关性，构件根据框 架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完 整。“。 2 1 2 框架和设计模式 框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。”。构 件通常是代码重用，而设计模式是设计重用，框架则介于两者之间，部分代码重用， 部分设计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用， 4 第= 章框架和设计模式 即在同一应用中能公共使用的抽象块；代码重用，即将通用模块组合成库或工具集， 以便在多个应用和领域都能使用；应用框架重用，即为专用领域提供通用的或现成 的基础结构，以获得最高级别的重用性。 框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中 反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码 表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示；设计模式是 比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一 特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模 式是软件的知识。 2 1 3 框架的作用 框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一 个大的应用系统往往可能由多层互相协作的框架组成。 由于框架能重用代码，因此从己有构件库中建立应用变得非常容易，因为构件 都采用框架统一定义的接口，从而使构件间的通信简单。 框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成 更小的构件。而且能描述构件间的内部接口嘲。这些标准接口使在已有的构件基础 上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入 框架中，构件设计者就能重用构架的设计。 框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它 划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能 进行沟通。 采用框架技术进行软件开发的主要特点包括： a )领域内的软件结构一致性好； b )建立更加开放的系统； c )重用代码大大增加，软件生产效率和质量也得到了提高； d )软件设计人员要专注于对领域的了解，使需求分析更充分； e )大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费 用降低，而参数化框架使得适应性、灵活性增强。 2 2 设计模式概述 在面向对象的编程中，软件编程人员更加注重以前的代码的重用性和可维护性。 每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方 案的核心。这样，你就能一次又一次的使用该解决方案而不必做重复劳动“。 每个模式是由三部分组成的一个规则，这个规则描述特定环境、问题和解决方 案之间的关系。简单的说，没有个模式是独立的实体，每个模式都存在着相互支 5 第二章框架和设计模式 持，但支持的程度不同：大的模式可以内嵌小的模式，同等层次的模式并列存在， 而小的模式被嵌入到大的模式之中。设计模式的基本思想是，公共的“习惯用法” 在软件设计中被不断重复发现，因此这些模式应该被有意识地归纳整理，并用于类 似同题的解决。 2 2 1 模式的优点 设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的 技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。 使用设计模式可以为软件设计带来很多好处： a ) 设计模式为开发者提供了好的设计经验，模式中所描述的解决方案是人们从不 同角度对一个问题进行研究。然后得出来最逶用、最灵活的解决方寨，其有效 性已经在很多设计中得到证实，其中蕴涵了有经验的程序员的设计经验。将经 过验证的技术表述为模式可以使新系绕的开发者更容易理解，并且以过去成功 的开发经验指导当前的软件开发，避免传统上靠次试验而导致的失误。 b ) 设计模式为项目之间、程序员之间重用霭向对象代码提供一种方便的途径，使 得重用成功设计和结构更加容易。每个模式都是软件设计中的可重甩元素，一 个熟悉设计模式的设计者可以在其设计中直接应用模式，而无需重新设计和开 发它们。一个没有经验的程序员也可借助于设计模式提高设计水平。多个模式 可以组合起来构成完整的系统，这种基于模式的设计具有更大的灵活性、可扩 展性和更好的可重用性，同时，基于模式的设计还能够加快设计的速度，并提 高开发队伍的生产力和软件的质量。 c ) 模式为程序员提供了共同的词汇。当一个模式被写出来，它就可以在程序员之 间讨论，这使得程序员可以更好地合作和分享他们的智慧，也可以避免讨论问 题时的歧义。 d )设计模式的基本思想是将程序中可能变化的部分与不变的部分分离，尽量减少 对象之间的祸合，当某些对象发生变化时，不会导致其他对象都发生变化。为 了实现这个目标，模式中一个常见的方法是在类或对象阔增加一个中间类或对 象，这样做的结果不仅使得代码更容易扩展和维护，而且也令程序更容易读。 e ) 通过明确地表述类和对象的关系和意图，设计模式甚至可以改进现有系统的文 档和维扩。可以说，设计模式帮助设计者更快更好地设计。 常用的设计模式有很多，首先，需要了解的是参考文献 1 5 ，这本书讲2 3 种主 要的模式，包括：抽象工厂、适配器、外观模式等。还有其他的很多模式，估计有 1 0 0 多种。 每一种模式都是针对一定的问题提出的，没有一种模式是万能的。所以，我们 在进行系统开发的时候要针对具体情况采用不同的模式。 6 第二章框架和设计模式 2 3 埘c 模式概述 m v c 模式是一种目前广泛流行的软件设计模式，早在7 0 年代，i b m 就推出了 s a n f r o n s c i s i c 项目计划，其实就是m v c 设计模式的研究。1 。近来，随着j 2 e e 的成 熟，它正在成为在j 2 e e 平台上推荐的一种设计模型，也是广大j a v a 开发者非常感 兴趣的设计模型。m v c 模式也逐渐在p h p 和c o l d f u s i o n 开发者中运用，并有增长趋 势。随着网络应用的快速增加，删c 模式对于w e b 应用的开发无疑是一种非常先进 的设计思想，无论选择哪种语言，无论应用多复杂，它都能为你理解分析应用模型 时提供最基本的分析方法，为你构造产品提供清晰的设计框架，为你的软件工程提 供规范的依据。 2 3 1w v c 设计思想 m v c 即把一个应用的输入、处理、输出流程按照w o d e l ，v i e w ，c o n t r o l l e r 的 方式进行分离，这样一个应用被分成三个层：模型层、视图层、控制层。 ! ：堕墨， ( 控制器) l 厂、d 浏2 实例化 览 4 国 器 室 i o r a c l e9 i f l ! ：堕壁 4 ( 勰) h a ( 模v a b 型e a ) np 叶 图2 1埘c 模式结构图 ( 1 ) 视图( v i e w ) ：代表用户交互界面，对于w e b 应用来说，可以概括为h t m l 界 面，但有可能为x t h 枷，x m l 和a p p l e t 。 随着应用的复杂性和规模性，界面的处理也交得具有挑战性。一个应用可能有 很多不同的视图，m v c 设计模式对于视图的处理仅限于视图上数据的采集和处理， 以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交给模型 来处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界 面的输入数据和请求传递给控制和模型。 ( 2 ) 模型( m o d e l ) ：就是业务流程状态的处理以及业务规则的制定。 业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并 返回最终的处理结果。业务模型的设计可以说是m v c 最主要的核心。日前流行的e j b 模型就是一个典型的应用例子，它从应用技术实现的角度对模型做7 进一步的划分， 以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这 种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对个开发者来 说，就可以专注于业务模型的设计。m v c 设计模式告诉我们，把应用的模型按一定 7 第二章框架和设计模式 的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。 抽象与具体不能隔得太远，也不能太近。瓣c 并没有提供模型的设计方法，而只告 诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用面向对 象编程来做比喻，m v c 定义了一个父类，告诉它的子类你只能做这些，但没法限制 你能做这些。这点对编程的开发人员非常重要。 ( 3 ) 控制器( c o n t r o l l e r ) ：可以理解为从用户接收请求，将模型与视图匹配在一 起，共同完成用户的请求。 划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么 样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的 数据处理。例如，当用户点击一个链接，控制层接受请求后，并不处理业务信息， 它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。 因此，一个摸型可能对应多个视图，一个视图可能对应多个模型。 2 3 2m v c 的优点 大部分用过程语言比如a s p ，p h p 开发出来的w e b 应用，初始的开发模板就是混 合层的数据编程例如，直接向数据痒发送请求并用h t m l 显示，开发速度往往比较 快，但由于数据页面的分离不是很直接。因而很难体现出业务模型的样子或者模型 的重用性。产品设计弹性力度很小，很难满足用户的需求变化。蝌c 要求对应用分 层，虽然要花费额外的工作。但产品的结构清晰，产品的应用遥过模型可以得到更 好地体现m 。 首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快 速变化下，可能有多种方式访问应用的要求。例如，订单单模型可能有本系统的订 单。也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说 订单的处理是一致的。按m v c 设计模式，一个订单模型以及多个视图即可解决问题。 这样减少了代码的复制，即减少了代码的维护量，一且模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于 接口的使用。 再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的 改变。一个应用的业务流程或者业务规则的改变只需改动m v c 的模型层。 控制层的概念也很有效。由于它把不同的模型窥视图组合在一起完成不同的请 求，因此，控制层可以说是包含了用户请求权限的概念。 最后，它还有利于软件工程化管理。由十不同的层各司其职，每一层不同的应 用具有某些相同的特征，有利于遥过工程化、工具化产生管理程序代码。 2 3 3m v c 的缺点 ( 1 ) m v c 的设计实现并不十分容易，理解起来比较容易，但对开发人员的要求 8 第二章框架和设计模式 比较高。m v c 只是一种基木的设计思想，还需要详细的设计规划。 ( 2 ) 模型和视图的严格分离可能使得调试困难一些，但比较容易发现错误。经 验表明，m v c 由于将应用分为三层，意味着代码文件增多，因此，对于文件的管理 需要花费较多时间。 ( 3 ) 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循m v c ，使模 型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低 运行效率。 综上所述，m v c 是构筑软件非常好的基本模式，至少将业务处理与显示分离， 强迫将应用分为模型、视图以及控制层，使得你会认真考虑应用的额外复杂性，把 这些想法融进到架构中，增加了应用的可拓展性。如果能把握到这一点m v c 模式会 使得你的应用更加强壮，更加有弹性，更加个性化。 2 3 4 用m v c 开发w e b 系统的两种主要模式 j s p 技术规范给出了两种使用j s p 开发w e b 应用的方式，这两种方式可以归纳 为m o d e l1 和m o d e l2 ，这两种模型的主要差别在于它们处理业务的流程不同。 m o d e l1 称之为j s p + j a v a b e a n 模型“”。在这一模型中，j s p 页面独自响应请求 并将处理结果返回给客户，所有的数据通过j a v a b e a n 来处理，j s p 实现页面的表现。 m o d e l1 实现了页面表现和业务逻辑相分离。然而使用这种方式就要在j s p 页 面使用大量的j a v a 代码，当需要处理的业务逻辑很复杂时，这种情况会变得非常糟 糕。从工程化的角度考虑，它有一些不足之处： a )应用的实现一般是基于过程的，一组j s p 页面实现一个业务流程，如果要进行 改动，必须在多个地方进行修改。这样非常不利于应用扩展和更新。 b )由于应用不是建立在模块上的，业务逻辑和表示逻辑混合在j s p 页面中没有进 行抽象和分离。所以非常不利于应用系统业务的重用和改动。 所以，m o d e l1 不能满足大型应用的需要，但是对一于小型应用，因为该模型 简单，不用涉及诸多要素，从而可以很好地满足小型应用的需要，所以在简单应用 中，可以考虑m o d e l1 。 m o d e l2 ，如图2 - - 2 所示，称之为j s p + s e r v l e t + j a v a b e a n s 模型。这一模型结 合了j s p 和s e r v l e t 技术，充分利用了j s p 和s e r v l e t 两种技术原有的优势。这个 模型使用j s p 技术来表现页面，使用s e r v l e t 技术完成大量的事务处理，使用b e a n 来存储数据。s e r v l e t 用来处理请求的事务，充当一个控制者的角色，并负责向客 户发送请求。它创建j s p 需要的b e a n 和对象，然后根据用户请求的行为，决定将哪 个j s p 页面发送给客户。 9 第二章框架和设计模式 ， 、 ， 、 虿 l 控日 令离 l l j 1s e r l l 数据库j l 。、j 、l帮订 一1曼! ：r 应用服务器 数据库服务器 图2 2 w o d e l2 从开发的观点看，m o d e l2 具有更清晰的页面表现，清楚的开发角色的划分， 可以充分利用开发团队中的网页设计人员和j a v a 开发人员。这些优势在大型项目中 表现得尤为突出，两页设计人员可以充分发挥自己的美术和设计才能来充分表现页 面，程序编写入员可以充分发挥自己的业务逻辑处理思维，实现项目中的业务处理。 另外，从设计结构来看，这种模型充分体现了模型视图控制器( u v c ) 的设计架构。 事实上，现存的很多开发框架都是基于这种模型的，充分实现了m v c 。 2 4j 2 e e 应用体系 j 2 e e ，是适用于创建服务器应用程序和服务的j a v a2 平台企业版。 j 2 e e 是一种利用j a v a2 平台来简化企业解决方案的开发、部署和管理相关的 复杂问题的体系结构“”。j 2 e e 技术的基础就是核心j a v a 平台或j a v a2 平台的标准 版，j 2 e e 可以理解为一个企业级的中间件体系或平台。它把多种分散到网络上的资 源和应用连接起来，为构造和管理、运行可伸缩的企业级业务应用提供了一系列的 应用组件和一个运行环境。从物理上看，j 2 e e 环境可分布驻留到一个以上的服务器， 单一的业务应用能够以一组分布式组件的形式部署到网络上的一个或者多个服务 器。 2 4 1j 2 e e 多层应用体系的介绍 在传统的两层结构模式中，客户机与数据库服务器通过数据库桥a p i 直接通信， 这些数据库桥a p i 中的典型代表就是o d b c 和j d b c 叫1 。在传统c s 结构中，客户层 是表现层和企业逻辑层的结合，而服务器则在逻辑上属于数据层。 c s 结构，它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势， 将任务合理分配到c l i e n t 端和s e r v e r 端来实现，降低了系统的通讯开销。目前大 多数应用软件系统都是c s 形式的两层结构，由于现在的软件应用系统正在向分布 第二章框架和设计模式 式的w e b 应用发展，w e b 和c s 应用都可以进行同样的业务处理，应用不同的模块 共享逻辑组件。因此，内部的和外部的用户都可以访问新的和现有的应用系统，通 过现有应用系统中的逻辑可以扩展出新的应用系统。但在w e b 时代，二层化应用通 常不能体现出很好的伸缩性，因而很难适应i n t e r n e t 的要求“”。 c s 结构的缺点有： a ) 安装成本高，因为数据库驱动程序必须在每台客户机安装和设置； b )数据库驱动程序升级的成本高： c )数据库的变更成本高： d )企业逻辑的改变代价高。在c s 结构中，企业逻辑是在客户器中实现的，因此 企业逻辑的变更意味着重新修改原代码和重新编译和安装： b s 形式的多层结构，它是随着i n t e r n e t 技术的* 起，对c s 结构的一种变化 或者改进的结构。在这种结构下，通过浏览器显示用户工作界面，而极少部分业务 逻辑在前端( b r o w s e r ) 实现，主要业务逻辑在服务器端( s e r v e r ) 实现。这样就大大简 化了客户机载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本。 从目前的技术看，局域网建立b s 结构的网络应用，并通过i n t e r n e t i n t r 8 n t 模式 下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现 不同的人员，从不同的地点，以不同的接入方式( 比如 a n ，i n t e r n e t ，i n t r a n e t 等) 访问和操作共同的数据库：它能有效地保护数据平台和管理访问权限，服务器数据库 也很安全。特别是在j a v a 这样的跨平台语言啦现之后，b s 架构管理软件更是方便、 快捷、高效。 多层结构是在传统的两层结构中加入几层实现的，在多层结构中，表现层、业 务逻辑层和数据层在物理意义上被分开，因而每一层可以独立地进行扩充和修改而 不影响应用程序的其它部分。典型的多层结构的应用就是用网络浏览器通过w e b 服 务器执行c g i 和数据库通信。在该模式中，浏览器和部分的w e b 服务器程序构成了 表现层，业务逻辑则完全集中在a p p l i c a t i o n 服务器执行的程序，数据库则完全是 数据层。 j 2 e e 提供了一套标准a p i ，用于开发分布式结构的应用，这个框架的实际实现 留给了第三方厂商。部分厂商只是专注于整个j 2 e e 架构中的特定组件，例如a p a c h e 的t o m c a t 提供了对j s p 和s e r v l e t s 的支持，b e a 系统公司则通过其w e b l o g i c 应用 服务器产品为整个j 2 e e 规范提供了一个较为完整的实现。 j 2 e e 的对象模型典型的三层模型”，整个应用系统由客户层( c l i e n t ) ，w e b 层 ( w e b ) 、业务逻辑层( b u s i n e s sl o g i c ) 、企业信息系统层( e e n t e r p r i s ei n f o r m a t i o n s y s t e m s ) 构成。在实际应用中，一个复杂的系统可能要多于这三层，而一个简单的 系统则要少一些。 第二章框架和设计模式 ( 1 ) 客户层( c 1 l e n tt i e r ) j 2 e e 应用可以是基于w e b 的，也可以是不基于w e b 的。 在基于w e b 的j 2 e e 应用中，用户的浏览器在客户层中运行，并从一个w e b 服务 器上下载w e b 层中的静态m 札页面或由a s p 或s e r v l e t s 生成的动态h t m l 页面。 在不基于w e b 的j 2 e e 应用程序中，一个独立的客户程序，可以不运行在一个 g r m l 页面中，而是运行在其它一些基于网络系统( 比如手持设备或汽车电话) 中的 a p p l e t 程序。在客户层中运行，并在不经过w e b 层的情况下访阎e n t e r p r i s eb e a n s 。 不基于w e b 的客户层也可能包括一个j a v a b e a n 类来管理用户输入，并将该输入发送 到在企业层中运行的e n t e r p r i s eb e a n 类来处理。 ( 2 ) 表示层( p r e s e n t a t i o nt i e r ) 表示层中的组件主要用来处理用户接口并与用户交互。j 2 e e w e b 组件可以由j s p 页面、基于w e b 的a p p l e t s 以及显示搬也页面嚣s e r v l e t s 组成。调用s e r v l e t 或 者j s p 页面的h t 地页面在应用程序组装时与w e b 组件打包在一起。就像客户层一样， 表现逻辑层可能包括一个j a v a b e a n s 类来管理甩户输入，并将输入发送到在业务层 中运行的e n t e r p r i s eb e a n 类来处理。运行在客户层的w e b 组件依赖容器来支持诸 如客户请求和响应及e n t e r p r i s eb e a n 查询等。 ( 3 ) 业务逻辑层( b u s i n e s sl o g i ct i e r ) 作为解决或者满足某个特定业务领域( 比如镶行、零售或金融业) 的需求的逻辑 的业务代码，由运行在业务层的e n t e r p r i s ej a v ab e a n 来执行。一个e n t e r p r i s e j a v ab e a n 从客户程序处接收数据，对数据进行处理，再将数据发送刭数据层存储。 一个e n t e r p r