【VC++开源代码栏目提醒】:网学会员在VC++开源代码频道为大家收集整理了“ASP.NET平台下对MVC模式的一个扩展 - 硕士论文“提供大家参考,希望对大家有所帮助!
Y 766S22 中山大学硕士学位
论文 ASP.NET平台下 对MVC模式的一个扩展指导教师:奎蠡熬握专业名称:盐篡赳筮性量堡监答辩委员会(签名) .答辩委员会三席:。
藤纠球答辩委员会委员:—— 二00五年六月中山大学硬士学位
论文 AsPrNET平台下对MvC模式的一个扩展 ASP.NET平台下对MVC模式的一个扩展 专 业:
计算机软件与理论 硕士生:郑权 指导教师:李磊教授 摘要 早期的w曲应用程序,由于受实现技术的限制,都是把用户交互界面和业务逻辑纠结在一起,这导致了
代码的复用和维护都非常困难。
随着技术的发展,使得w曲应用程序实现Mvc模式成为可能。
DotNET环境下的w曲开发平台AsPNET,提供了对MVc Modd 1的实现环境。
但AsPNET对Mvc模式的实现并不完善,在模型、视图、控制器、数据库四者之间的透信中: 11控制器过多地作为模型和视图之间信息传递的中介者,导致控制器过度依赖于视图和模型。
∞控制器直接调用模型内封装的业务功能,但它们之间存在一些难以界定职责的行为,如日志、授权等.这些行为既不应该在控制器内实现,又不应该在模型内实现。
在AsP.NET中,这往往导致
代码的重复分发并破坏程序的结构。
31模型直接和底层数据库会话。
导致模型依赖于底层数据库。
这些不完善之处使得w曲应用的系统结构逐渐变得模糊并且难以维护和扩展。
z.Mvc是AsPfNET平台下对Mvc模式的一个扩展,它重新定义了模型、视图、控制器、数据库四者之间的通信,能有效地解决模型、视图、控制器、数据库之间的耦合所带来的种种问题。
除此之外,z-Mvc还从实用的角度出发,把应用系统中与业务逻辑无关的共性操作分离出来,集成到在厶Mvc扩展中供开发者调用或者透明实现。
简化了开发者的工作量,让他们更好地专注于业务处理逻辑。
关键字:模型,视图,控制器,MVc,AsPNET。
.!坐塑主兰竺丝壅垒竖!坚!鱼!翌坚∑里塑塞塑二尘芝壁 An王弦tensiOn of MVC Pattem based on ASP.NET Plat60rm Major:c0Inputer Softwafe姐d Theory NⅫe:zheng Quan Supervisor:Pmf.U I就 Abstract Bemg restricted by technOlogy,web applications of early ages put both iⅡte瑚【ction in【erfaces孤d processjⅡg 10舀c all togc也eL so it is唧ha—to reusc and maintajn the印pⅡcad∞code. 1n tlle movement of tecllnology,nowadays it is p0Ssible for web印脚icadons to蛔lpl咖曲t theMVC pattem.And ASP.NEr’Ⅱle main web develop巾latfo珊based oⅡDoⅡ咂T’also provjdcs柚eⅡvi咖ment to iInpleInent MVC Modell. But,the implementation of MVC Pancm on ASPNET is not g∞d e∞ugh.1ll恤c0啪munication among 加Odels、Views、咖,holle糟and a datab鹤e: 1)cbⅡtrone巧act as agenci髂betwcen models and Views redund蛐Il y.As a Ie鲫1t,nlecontroneIs d印end on models柚d vidws麟cessively. 2)oDntroUefs call me busiIIess in models direcⅡy.But func虹ons衄capsulated actIlally,be柳Ben mOdels卸d contfolle稻lhere am soⅡ地们tioI塔whoSe re印。
琳ibilny are蜘biguous t0panidon,likc logging,authofizad∞.11lat n地ans t110se acti叩s sllouldⅡ0t be carried out incontrOllers,neiIher jn models.1n ASP.M玎,tllis situ撕彻will lead to repeated dist曲ute of codesand m衄age to山e appli∞tion stmctIIre. 3)Models access database djrcctly,勰a result,models put an dependency on databa∞. All of those s110rtcornings make the stmcIure 0f web applicatio璐bcing more and moreambiguous,and harder t0 ma曲ain 0r exteⅡd. The Z-MVC is aIl麟t蛐sion 0f MVC patlcm based on AS P.N盯platfornl.玉MVC re-defi北sthe cOmmunicaIion am叩g model、view、contmller and datab粘e,and jt will settle those probl锄sbrou曲Iby Ihe coupliⅡg of tlle fouf pans.Besides,玉MVC s印缸ates卸d锄egrates舶m webapplicationS the most common operanons,which are irrelativc wjth business 109ic,and provideinterfaces for programmer lo reuse tllem’or carry Out lhem transparenUy.So乙MVC is also apfacIicalt001 which alleViates the burdeⅡof programmers and makes them focus on business logicmore inlently.Keywords: Model,C0nlroll er’ Ⅵcw,MVC,ASP.NETa ¨中山大学硕士学位
论文 ASP.NET平台下对Mvc模式的一个扩展 第1章 前言 1.1问题背景 在最近几年中,随着互联网技术的发展和新的商业模式的出现,对于企业级应用来说,最大的变革奠过于把系统部署到w曲服务器上。
它带来很多好处;不需要安装客户端软件,接入、维护也很方便,它基于统一的w曲浏览器的用户界面,可以随时随地得为用户提供服务。
但是,早期的we b应用程序的开发技术。
并不能很好地胜任这一要求.^sP帆{PqSP等技术,都将业务处理逻辑和用户交互界面纠结在一起,很显然。
这种耦合使得界面设计的修改和业务逻辑的变动在大型应用程序中既困难又昂贵,因此,在构建W曲应用系统中,把交互界面和处理逻辑相互剥离就显得尤为重要。
后来,随着技术的发展,构建W曲应用程序的两大主流平台J2EE和Do吐咂T,都提供了对MVC(Model模型,view视图,con仃ouer控制器)模式的实现,使交互界面和处理逻辑的分离首次成为可能。
MVc模式起源于20世纪70年代的后期,由研gveRe∞skaug在small-ta撒80的GUl (图形用户界面)设计中首次提出。
从那以后,在大多数的GIⅡ设计思路中,它都扮演着非常重要的角色。
如果以用户交互界面为关注点,Mvc架构模式把系统划分为模型一视图一控制器三个层次。
对于应用系统中的一个用户交互界面,它常常涉及到三种不同角色: ●表示部件 ●数据处理部件 ● 输入输出调度部件 表示部件就是与用户交互的界面,它把系统中的数据展现给用户。
数据处理部件用于加:【和访问数据。
输入输出调度部件是表示部件和数据处理部件之间的联系桥梁。
比如,同一个交互界面中录入的不同的订单信息,可能要调用不同的数据处理部件来处理,然后又根据不同的处理结果调用不同的交互界面反馈给用户。
】中山大学硕士学位
论文 ASP肛T平台下对Mvc模式的一个扩展 如果每个用户交互界面都采用以上三种角色的划分,在系统架构上,就实现了一个MVC架构模式。
在MVc中,M0del对应于数据处理,view对应于输出。
contmHer对应于输入输出控制。
应用MVC模式可以有效地避免数据处理、数据表示、程序输入输出控制等不同的内容纠结在一起,从而简化系统的维护,提高可扩展性、灵活性和重用性。
以上只是对M、℃模式的一个大致的描述,在不同的环境中(如桌面单机模式和B幅模式)和不同的平台中(如ASPNET和Struts),Modcl—View—Contmuer三者的具体组成和相互间的通信都是不一样的,本文第二章将对此做进一步描述。
1.2问题提出 AS P-NET是微软公司推出的D004ET环境下的一个W曲开发平台,它提供了一个实现Mvc模式的环境。
也就是说,在AsP.Nl玎环境下开发的w曲应用程序,是实现MVc模式的。
为叙述方便,在此把“提供一个实现MVc模式的环境”叙述为“实现眦”。
但是,在具体使用的过程中,发现AsP脚’对MVc模式的实现并不完善。
直观易用、所见即是所得是微软公司产品的一贯风格,但它也破坏了了程序的结构:虽然利用强大的面向对象开发工具,但写出来是居于过程的冗长的
代码。
通过分析As P.NET对MVc模式的具体实现,我们可以得到模型、视图、控制器、数据库四者之间的
通信图。
图1.1:AS尸.NET中模型、视图、控制器、数据库四者问的通信 AsENET对Mvc模式实现的不完善在于: 11控制器过多地作为模型和视图之间数据传输的中介者,导致控制器过度依赖于视图和模型,并产生很多臃肿而又高耦台的
代码。
21控制器直接调用模型内封装的业务功能,但控制器与模型之间存在一些难以界定职责 2中山大学硕士学位
论文 ASn4ET平台下对Mvc模式的一个扩腱却又破坏程序结构的行为,这些行为跨越了多个对象体系,如验证权限,记录日志等。
它们既不应该在控制器内实现,又不应该在模型内实现。
如果不针对这种行为明确提供一种处理机制,那么它们都会不负责任地一一要么在控制器内实现,要么在模型内实现。
无论是前者还是后者,这都会产生重复分发的
代码,并破坏程序结构的清晰和简洁。
31模型直接和底层数据库会话,导致模型依赖于底层数据库。
这些不完善之处诱使产生大量的重复的相互纠结的
代码,使得W曲应用程序的系统结构逐渐变得模糊并且难以复用和扩展。
问题: 如何完善AsP-NErr对MVc模式实现的不足?如何重新定义模型、视图、控制器、数据库的通信? 1.3本文工作 针对以上所描述的不足之处,本文提出了一个在AsP-NEr平台下对MVC模式的扩展。
简称二Mvc。
z小nrc的的最终目标是最大限度解除模型、视图、控制器、数据库四者之间的耦台,提高W曲应用程序的可复用性、易扩展性、结构清晰性。
针对“控制器过多地作为模型和视图之间信息传递的中介者”这一问题,二Mvc提出了模型一视图之间的双向绑定机制,使得信息传递不用显式使用控制器为中介,从而减少了信息传递的成本,并使得控制器对视图和模型的耦合度大大降低。
针对“控制器和模型之间存在一些难以界定职责却又破坏
程序结构的行为”这一
问题,玉Mvc把面向切面编程思想引入到Mvc模式中,提出了在模型层上构筑一个模型服务层。
使得不同的关注可以在不同的切面模块中实现,提高了程序
代码的可读性、可复用性和可扩展性。
针对“模型直接和底层数据库会话,导致模型依赖于底层数据库”这一问题,z{dVc在模型层和底层数据库间增加了一个对象一关系映射层,同时探讨了如何解决DotNl玎数据类型和关系数据库数据类型不匹配的问题。
为了在模型一视图之间使用双向绑定机制,z.Mvc在视图层定义了双向绑定的文法。
双向绑定的信息加插在视图中,控制器由此获知视图一模型中各个属性的一一对应关系。
为了在双向绑定的过程中,透明地实现输入合法性校验、编码转换等操作,z·MVC在 3中山大学硕士学位
论文 ASENET平台下对Mvc模式的一个扩展模型层中定义和实现了业务实体属性的配置,从而简化程序员的
工作量。
1.4研究意义 本文的实用性在于:AsPNET是当今一个主流的w曲应用程序开发平台。
使用者有几十万之多。
本文所研究的Z-MVC扩展,能够在AsP.NET平台中,有效解除模型、视图、控制器、数据库四者之间的耦合关系。
同时,在w e b应用上安插二MVc扩展包。
可以构建可复用的软件
系统框架,使得整个框架结构基本不做修改或做很少的修改就可应用到其它相似的系统,因此达到多层次的软件复用。
因此,吕MVc扩展可以减少
软件维护的工作量,提高软件的质量,缩短软件的开发周期,并能很好地适应系统功能的变化,特别适合于电子商务、电子政务等的应用开发。
目前在As P.NET平台下对Mvc模式的扩展并不多“’,本文写作时,一共检索到的只有两个项目;NWAF和Maverick,作者认为它们做得并不成功:它们的目的都是让ASmqET实现MvCModel2,但是这会导致AsP.NET丧失白有特性,变得不伦不类。
本文的创新之处在于:(1)玉MVc对在AsP.NET平台下的MVC扩展提出了自己的尝试,并指出:AsP.NET本质上是对MVCModc】l的实现,它和MVCModeJ2的实现是相冲突的,所以对ASP.NET的MVC扩展应专注于模型、视图、控制器、数据库四者之间的解耦,而没有必要引入对Mvc Model 2的实现。
(2)z- ̄Ⅳc是在AsPNl玎环境中首次实现了模型一页面的双向绑定机制的MVC扩展。
1.5结构安排 第2章描述了本文的背景。
包括MVC模式的概念,以及各种不同的MVC模式。
同时简述了J2EE世界和DotNET世界中对MVc模式的各自实现。
第3章详细描述AsP.NET对MVc模式的实现是有哪些不足之处,并随即提供一个直观的原始的解决思路,这就是z-M、,c的动机。
然后从这个动机出发。
归纳了z柏,c的目标和设计。
注…:使用AsPNET的程序员虽然根多,但扩展MVc模式的有关文献、项目却银少,这也让作者感到惊讶。
在J2EE世界中,类似的项目可谓百花齐放,层出不穷.作者认为第一个原因是微软的技术体系自成一家,从操作系统,web应用服务器.开发平台,开发工具统统都是自己实现.这种技术体系封闭使得第三方实现的可能性太为减少.第二个原因是AsP_NET非常具有自己的特色t它得底层实现机制与J2EE平台下得诸多框架人不一夸.这也使在保留ASP.NET特色前提下扩展MVc模式变得困难· 4中山大学硕士学位
论文 AsP’NET平台下对MVc模式的一个扩展 第4章是关于Model层的分析、
设计和实现。
主要内容是1)指出在AsP.NElr中应放弃自定义Dataset类型而选择简单对象类型来表示模型;2)解决O,R映射中DotNl玎类型与数据库数据类型不匹配的问题;3)实现居于模型属性的配置和约束校验等功能;3)在Model层上封装一个模型服务层,提供面向切面的服务。
第5章是关于Ⅵew层和Con仃0uer层的分析、。
主要内容是如何让控制器作为调用者,使Ⅵew层和Model层之间实现双向绑定.同时还涉及到在Ⅵew层定义双向绑定的文法。
在AsP.NET中,因为视图和页面控制器又是紧密联系的,所以把Ⅵew层和con们ller层的内容放到同一章。
第6章是关于厶Mvc扩展在“国旅假期”旅行社
管理系统的应用,它使开发
代码量大大减少,并且体系结构变得更加清晰,并适应各种不同的表现界面。
第7章简要评估了二Mvc,并指出了乙MVc可以继续优化和扩展之处。
5!型型望墅生兰堂竺丝!L. 竺曼!里!!鱼!型坚∑兰燮壅塑二!堑:壁 第2章 背景 这一章是本文背景的综述。
2.1描述了最初的w曲应用程序的是什么样子的,它又是如何一步步地演化为当今的N层体系结构以便适应更复杂的企业应用。
2.2—2.4是对MVc的一个总体描述。
2.2说明了什么是MVc,以及它有什么优点,2.3则描述了两种MVc的变体:主动模式和被动模式。
对于w曲应用来说,由于模型的更新不能直接通知视图,所以它只能使用被动模式。
2.4更具体地描述了被动模式下的Ⅵ,eb应用的构建的两种方式,以页面为中心时,使用Mvc Modell, 以控制器为中心时,使用MvcModeJ2。
2.5砣.6对比了MVcModel2和MVcModel l所对应的代表性实现:S咖ts和AS P.NETo使用J2EE技术的MVc框架大多是对MVcModel2的实现,而使用DotNEl’技术的As P.NET则是对MVcModel 1的实现。
2.7是一个小插曲,用于澄清N层体系结构和MVC分层两个概念中的容易混淆之处。
2.8简要介绍了
开源世界中对ASP.NET做出扩展的两个MvC框架:Maverick和N恸师,同时指出它们设计上的不足之处:生硬地引入对MVC Model 2的实现却导致了ASP.Nl玎特性的丧失。
2.1 Web应用体系结构 首先要澄清的是:本文所定义的层是指逻辑概念的层(1ayer),并非指物理分布意义上的层(ticT)。
访问W曲站点的一次交互可能涉及到客户浏览器、应用服务器、数据库等三个不同的物理分布(tier),但这并不代表W曲应用程序里面就具有清晰的层次(1ayer)划分, 2.1.1 静态体系结构 在web发展的初期,web应用通过静态HrML页面发布和共享信息。
其体系结构如下图2.1所示。
用户通过浏览器向服务器发送请求,服务器接收用户端的请求,向客户端浏览 6中山大学硕士学位
论文 AsP.NET平台下对Mvc模式的一个扩展器发送所请求的页面。
在这种结构下,站点上的页面是静态的,无法根据实际使用情况做动态的调控,所以w曲应用的开发者必须手工更新服务器上的网页来向用户提供最新的信息。
请求 叫 浏览器}..响应 _l嘏务器i 图2-1:静态web应用的体系结构 2.1.2 单层体系结构 基于页面的开发技术(如ASP、PHI,和JSP)的出现,允许开发人员将脚本直接嵌入到Hnm.面中,从而简化了编程模型。
其
常用体系结构如图2~2所示。
用户通过浏览器向服务器发送请求,w曲服务器接收客户端发送来的请求,对请求进行分析,如果请求是静态页面,那么就将所请求的页面发送到客户端;如果请求的是动态页面,那么就执行此动态页面,并将执行结果发送给客户端。
动态页面中的脚本程序可以和数据库服务器进行交互,通常执行的结果是对数据库的查询、更新、删除、创建等操作。
浏览器: {一请求 一——响应 』戮篡鬃 图2.2:单层体系结构的Web应用 Ⅵrcb服务器可以根据用户的请求动态更新页面上的信息,w曲信息提供者可以通过改变数据库中的数据向用户提供最新信息,而不需要逐个更改页面。
用户可以通过这些动态页面向数据库中输入信息,从而增强了用户和服务器的交互性.也大大提高了程序员开发动态w曲网页的效率。
无论是采用何种开发技术(如AsP,PHP,JsP)的单层w曲体系结构,它们都有一个共同点,就是开发人员将脚本直接嵌入到H1ML页面中,这样会导致业务逻辑、业务的具体实现以及界面显示完全纠缠在一起,也就是说业务逻辑、数据库操作都落到了表示层,所以本文定义其为单层体系架构。
这样的系统,无论程序员如何小心翼翼得提炼重复使用的函数.. 7中山大学硕士学位
论文 AsP_NET平台下对Mvc模式的一个扩展随着系统复杂性和功能的增加,最终,系统还是无可避免得变成一堆混乱不堪的意大利面条,所以系统的结构缺乏清晰严谨,可维护性可重用性都非常差。
2.1.3 N层体系结构 建立可维护、可扩展的站点,开发高效率、高伸缩性的应用程序、实现跨平台、跨Inlemet的应用集成是摆在无数开发者面前的任务,传统开发方式及技术面临了困难j在这个前提下,出现了N(多)层体系结构。
层架构模式组织成一个层次结构,每一层为上层服务,同时也作为下层的客户端。
在一些层次系统中,除了包含一些输出函数外,内部的层只对相邻的层可见,层的调用通过决定层间如何交互的协议来定义。
这种风格支持基于可增加抽象层的设计。
这样,允许将一个复杂问题分解成一个层堆栈的实现。
由于每一层最多只影响两层,同时只要给相邻层提供接口,允许每层用不同的方法实现,因此为软件重用提供了强大的支持。
一般地,我们将w曲应用程序功能分为三个方面,对应三层架构模式。
它们是数据层(datalayef)、业务层(busine∞layer)和表示层(pr∞∞l撕on laycr)。
数据层;包含数据存储和与它交互的组件或服务,比如对具体数据库的
查询、更新、删除等。
这些组件和服务在功能上和业务层相互独立(尽管在物理上不必一定相互独立~它们可以在同一台服务器上)。
业务层:包括一个或者多个组件服务。
它们应用业务规则、实现业务逻辑并和数据层通讯,完成应用程序运行所需要的数据处理。
表示层:从业务层获得信息并显示给用户。
该层同时也负责和用户进行交互,比较返回的信息并将信息回送给业务层进行处理。
可见,数据层与数据库打交道,负责对数据的处理加工;业务层执行具体的业务逻辑和业务规则,表示层与用户交互,把信息转换成对于用户有意义的内容。
w曲应用的多层体系结构如下图所示。
诩览器 服磐器 圈:圈-。
困,l圄 图2-3:N层体系结构的Web应用 8中山大学硕士学位
论文 ASP.NET平台下对Mvc模式的一个扩展 多层体系结构具有如下优势:● 结构清晰,富有扩展性和伸缩性。
每一层都可以独立地修改。
比如业务规则变化时,我 们可以修改业务层,从数据层接受相同的数据,并把这些数据传递到表示层,而不用担 心出现歧义;我们可以修改表示层,使得对于站点外观的修改不必改动下面的业务层逻 辑;我们也可以修改数据层,适应不同数据库系统之间的移植。
分层的设计方式有效地 把需求的变化所引起的系统修改局限在最小的范围内,提高了软件的重用性。
· 瘦的客户端。
客户端应用程序可以写得很小,而把大多数工作交给业务层处.