搜索
毕业设计（论文）外文文献翻译文献、资料中文题目：MVC设计模式文献、资料英文题目：THEMVC-WEBDESIGNPATTERN文献、资料来源：文献、资料发表（出版）日期：院（部）：专业：班级：姓名：学号：指导教师：翻译日期：2017.02.14MVC设计模式RalphF.Grove计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州groverf@jmu.eduErayOzkan计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州ozkanex@gmail.com关键字：web，web框架，设计模式，模型-视图-控制器模式摘要：模型-视图-控制器模式被引用为许多web开发框架的基础架构。然而，用于web开发的MVC版本随着原来的Smalltalk的MVC的演变而发生了一些改变。本文介绍了对这些变化的分析，并提出了一种独立的Web-MVC模式，用于更准确的描述MVC是如何在web框架中实现的。1.介绍模型-视图-控制器(Modle-View-Controller，MVC)设计模式被一些web应用框架作为基础架构，例如ASP.NET，Rails，以及Struts。MVC最初是在施乐帕克研究中心(Goldberg和Robson，1985)开发的Smalltalk编程环境中实现的。为了适应web框架，MVC已经演变成了另一种方式，最终成为一种不同于其他任何设计模式，也与原始的Smaltalk完全不同的模式的实现。本文的第一个目标是介绍MVC设计模式，其中包括它的原始形态(第2节)以及现代众所周知的用于web应用框架的变更后的形态(第3节)。第二个目标是对这个模式演变后发生的变化进行评估，同时呈现演变后版本的有效性(第3节)。最后，我们提出了一个标准的MVC-Web设计模式的描述，用于反映目前在web框架中模式的使用，同时又能保持原始的MVC中令人满意的特性。基于MVC的web应用框架的修订版本已经被提出了(Chun,Yanhua,和Hanhong,2003)(Barrett和Delaney,2004)。但是，本文并没有提出新的MVC架构，而是分析和记录了MVC模式从Smalltalk到适应web框架的演变。2.SMALLTALK中的MVCMVC设计模式是随着Smalltalk的编程环境而引入的，从此我们可以以模块化的方式来构建交互式应用程序(Krasner和Pope,1988)。正如这个名称所暗示的一样，MVC设计模式的功能可以分解为三大部分。模型(model)组件封装了应用程序的特定域的结构和功能，其本质就是包括了应用程序的状态以及改变这种状态的操作。模型还保持着对视图和控制器组件的依赖，当应用程序的状态发生变化时它会有通知。这种行为是观察者模式下的一个实例(Gamma,Helm,Johnson和Vlissides,1995)。视图(view)组件通过图形用户界面将信息呈现给用户。应用程序中不同的操作会有多个视图，不同的视图呈现给多个用户。视图也有可能是分层的，它由一些更小的(子视图)元素构成。当视图中包含的信息被更新时(通过对信息做出响应的模型组件)视图会得到模型的通知，然后视图会查询模型以获得它所要呈现的信息。控制器(controller)组件通过用户界面响应用户的操作，它负责将事件传递给模型然后执行操作。控制器与视图是一一对应的存在的，多层次的视图也因此在相应的控制器之间复制。当控制器接受到输入信号时，它首先将其传送到活动的子控制器，因此输入信号首先会被最低层级的控制器处理。用户的输入和输出形成了MVC的一个隐含的第四个组件。Smalltalk系统是基于图形显示和标准的用户输入设备，主要是键盘和鼠标。用户菜单被认为是一种虚拟类型的设备，它主要用于传送输入信号给控制器层，就跟键盘和鼠标一样。虽然菜单是在用户图形界面(GUI)中实现的，但是它们不被认为是视图组件。MVC设计模式的主要优点是将关注点分离和由此产生的模块化。这种设计将用户界面的呈现与用户输入的操作隔离了，同时也将这两部分与应用程序的状态和事件处理过程隔离了。这就使得当你修改或替换某一个组件时，无需修改甚至无需解会其他部分。它也可以通过为新的接口介质添加一个视图/控制器的组合，或者通过独立于其他组件为模型添加新的功能而增加其可扩展性。3.WEB框架中的MVCASP.NetMVC2是微软web开发框架的最新版本(Esposito,2010)。它为早期的基于WebForm的ASP.Net版本添加了MVC设计架构。ASP.NetMVC2为HTTP请求使用一个单一的处理程序，为每一个请求确定并实例化一个合适的控制器。控制器负责处理传入的请求，由模型策划事务处理，为后来的视图元素准备数据，同时激活视图元素使其产生响应。一个控制器类可以包含多个用于响应不同请求的方法，每个方法都作为一个独立的公共方法类。视图在ASP文件中被定义，它是一种带有生成动态内容的服务器脚本的HTML模板。每一个视图从激活它的控制器那里接收信息，无论是作为本地对象还是视图-模型对象，它都是独立的来自模型的数据的合辑，每一个都是为了特定的视图而设计。模型组件用于包含应用程序的逻辑和数据库访问。视图模型之间有一定的区别，数据结构用于传送信息给一个特定的视图元素，而应用程序模型则是域的实体和对它进行操作的相关事务。模型组件还提供对象关系映射，它隐藏了应用程序域对象映射到数据库表的细节。Rails是一个用于Ruby(Thomas和Hansson,2007)编程语言开发的web应用程序框架。HTTP请求在Rails中通过核心路由器来处理，核心路由器将请求转到相应的ActionController类和控制器组件内的方法。ActionController对象负责过滤请求参数，通过调用适当的模型元素的方法策划事务，并安排相应的视图响应。ActionController还安排视图元素访问来自模型的数据。控制器控制器元素也负责web会话管理，包括cookie管理。用户界面(视图组件)用过动态的模板文件呈现出来，这些动态模板就是嵌入了Ruby就脚本的标准HTML文档，类似于ASP,PHP,JSP等。视图元素可以在需要的时候访问模型组件并获取数据呈现出来。Rail模型组件包括封装应用程序逻辑的元素和事务处理(ActiveModel)，以及一个映射方案相关的对象(ActiveRecord)，该对象通过模型元素联合了每一个数据库表。模型也包括提供访问访问外部资源的ActiveResource元素。ApacheStruts2框架是基于Java企业版(J2EE)和Java服务器页面(技术)。Struts2视图组件就是JSP文档，这些文档嵌入了提供多种功能的标签，包括流控制(迭代，条件句)，访问JavaBean(模型组件)，以及简化HTML表单结构。一个Struts2web应用程序的控制器组件体现在方法里，这些方法即Java类。一个方法可以响应来自一个或多个JSP页面的用户输入，每一个方法主要负责验证用户输入并通过调用适当的模型操作来协调事务处理。方法通过一个XML配置文件或者通过Java注解机制来定义和配置。这种配置信息通过确定每个方法后的视图来控制web应用程序流，这取决于方法的结果。Struts2中的核心部分是值栈，值栈是用来存储视图和控制器之间的信息流并在需要的时候进行转换。这消除了许多涉及到处理HTTP请求参数和提供信息给JSP页面来显示的细节。所有这三个框架在将用户界面组件(视图)与应用程序逻辑(模型)和控制函数(控制器)分离的MVC模式中是保持一致的。当然，他们在某些方面与原始的MVC又有所不同。没有内部的视图-模型的依赖(观察者模式)：web应用程序中的模型组件不会通知视图元素在模型上发生了那些变化。相反，控制器决定视图的行为取决于模型的事务处理的结果。没有一一对应的视图-控制器对应关系：在原来的MVC中，每个视图元素有独立的控制器元素为了单独的视图元素而定义。前端控制器模型：所有这三个框架用了这种模式，单个控制器元素负责响应路由转入的HTTP请求，根据该请求的URL和配置数据。控制器制定视图动态：控制器决定了哪一个视图跟随者每一个控制器方法，基于方法的结果。这相当于一个本质上是视图=控制器的依赖。控制器元素负责数据验证：交易数据验证本质上是一个模型函数。验证逻辑可以推入到模型组件，但是负责执行验证函数的仍然是控制器。模型没有明确的定义：所有的框架都缺少对模型组件的明确定义。它被假定为包含应用程序逻辑和数据管理，但是没有明确的结构来定义模型或者将其与控制器干净的分离。模型类被实例化的需求：web框架实例化模型对象是由于处理事务的需要以及封装域实体的需要，而不是出于坚持一个设想的原始的MVC中的模型组件。但是，数据库或者应用程序的数据持续层可以是持久的模型组件。这些MVC模式的变化反映了客户端-服务器架构风格的基本性质优先于Web。视图平台(客户端)被物理地与其他组件分离开，因此视图组件在结构与操作方面与控制器和模型变得不那么紧密。同时，视图承担了一些模型的任务以便提供一个更具响应式的用户界面。控制新增加的任务(前端控制器的函数和视图测序)是必须的，因为需要显示的管理固有的用户体验控制流。4.MVC-WEB设计模式MVC-Web设计模式在这一节中描述了一个MVC模式中的模型在web应用程序框架中是如何被解释的。MVC-Web反映了MVC设计模式已经在web框架中实现了的革命性的变化。MVC-Web模型组件同程负责保留应用程序的状态。它的职责包括：数据呈现：维护一个数据库或一个抽象的数据接口事务处理：执行在应用程序状态上操作的的程序逻辑外部接口：管理与外部代理的互动，例如web服务或者遗留系统查询处理：为视图和控制器在响应查询是提供信息MVC-Web视图组件呈现了用户界面，包括数据呈现和输入设备。它的职责包括：信息检索和显示：呈现信息给用户；必要时查询模型以获得信息用来显示用户输入：呈现输入表单和允许用户与程序交互的控件客户端动态行为：为用户提供交互式的客户端体验(用JavaScript,Ajax,或者其他方式)；这可能包含输入实现，输入验证或其他应用程序特定规则和函数的实现，否则这将由模型来完成。MVC-Web控制器组件有三个主要职责：前端控制器：接受传入的请求并把它们路由到相应的处理程序方法处理：接受请求参数；验证请求参数的语法(这可能通过视图元素进行了重复验证)；通过调用模型元素来编排请求的处理程序控制流：调用相应的视图元素作为一个对请求正在被处理的响应，根据方法的结果来调用。MVC-Web模式的组件之间的交互有以下方式：模型-视图：视图元素会查询模型以获取信息用来显示给用户模型-控制器：控制器方法元素要求模型元素传送请求交易。模型函数可以包括执行程序逻辑，更新数据库，以及调用外部代理的服务。控制器元素会从模型请求数据并传递给视图元素控制器-视图：控制器元素对来自视图元素的请求做出响应。控制器也决定了哪一个视图元素会被呈现给用户以响应请求。控制器会通过视图元素为用户准备信息。这个版本的MVC不同于原始版本(Smalltalk)有以下几几个重要方面：观察者模式不是用来吧模型的更新通知给视图和控制器。控制器具有更突出的作用而不是用来传播更新视图和控制器之间没有一对一的对于关系了。现在已经是多对多的关系了。控制器必须能够从多个视图元素(前端控制模式)那里路由请求并能管理程序在响应中的流。控制器作为这个功能的一部分可能会从模型传送信息给视图。同样的程序逻辑(例如验证或者数据输入完成)可以被呈现在视图和控制器组件。这个可能分离的关注点，但是通过给用户提供更快的响应来提高了应用程序的效率。这个MVC-Web模式是为了反映当前的MVC在web应用程序中的实现。模式不要求稳定，然而，MVC-Web模式的改进一直在继续，例如在基于Ajax的用户界面中变得更加丰富更具响应效果。这些改变也许会模糊MVC-Web各个组件之间的界限并且降低这种模式提供的模块化的程度。参考1.