外文翻译-MVC设计模式

MVC设计模式

Ralph F. Grove

计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州

Eray Ozkan

计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州

关键字：web，web框架，设计模式，模型-视图-控制器模式

摘要：模型-视图-控制器模式被引用为许多web开发框架的基础架构。然而，用于web开发的MVC 版本随着原来的Smalltalk的MVC的演变而发生了一些改变。本文介绍了对这些变化的分析，并提出了一种独立的Web-MVC模式，用于更准确的描述MVC是如何在web框架中实现的。

1.介绍

模型-视图-控制器(Modle-View-Controller，MVC)设计模式被一些web应用框架作为基础架构，例如，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中的MVC

MVC设计模式是随着Smalltalk的编程环境而引入的，从此我们可以以模块化的方式来构建交互式应用程序(Krasner和Pope, 1988)。正如这个名称所暗示的一样，MVC设计模式的功能可以分解为三

大部分。

模型(model)组件封装了应用程序的特定域的结构和功能，其本质就是包括了应用程序的状态以及改变这种状态的操作。模型还保持着对视图和控制器组件的依赖，当应用程序的状态发生变化时它会有通知。这种行为是观察者模式下的一个实例(Gamma, Helm, Johnson和Vlissides, 1995)。视图(view)组件通过图形用户界面将信息呈现给用户。应用程序中不同的操作会有多个视图，不同的视图呈现给多个用户。视图也有可能是分层的，它由一些更小的(子视图)元素构成。当视图中包含的信息被更新时(通过对信息做出响应的模型组件)视图会得到模型的通知，然后视图会查询模型以获得它所要呈现的信息。控制器(controller)组件通过用户界面响应用户的操作，它负责将事件传递给模型然后执行操作。控制器与视图是一一对应的存在的，多层次的视图也因此在相应的控制器之间复制。当控制器接受到输入信号时，它首先将其传送到活动的子控制器，因此输入信号首先会被最低层级的控制器处理。

用户的输入和输出形成了MVC的一个隐含的第四个组件。Smalltalk系统是基于图形显示和标准的用户输入设备，主要是键盘和鼠标。用户菜单被认为是一种虚拟类型的设备，它主要用于传送输入信号给控制器层，就跟键盘和鼠标一样。虽然菜单是在用户图形界面(GUI)中实现的，但是它们不被认为是视图组件。

MVC设计模式的主要优点是将关注点分离和由此产生的模块化。这种设计将用户界面的呈现与用户输入的操作隔离了，同时也将这两部分与应用程序的状态和事件处理过程隔离了。这就使得当你修改或替换某一个组件时，无需修改甚至无需解会其他部分。它也可以通过为新的接口介质添加一个视图/控制器的组合，或者通过独立于其他组件为模型添加新的功能而增加其可扩展性。

3.WEB框架中的MVC

MVC2是微软web开发框架的最新版本(Esposito,2010)。它为早期的基于Web Form的版本添加了MVC设计架构。 MVC2为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元素。

Apache Struts2 框架是基于Java企业版(J2EE)和Java服务器页面( 技术)。Struts2视图组件就是JSP 文档，这些文档嵌入了提供多种功能的标签，包括流控制(迭代，条件句)，访问Java Bean(模型组件)，以及简化HTML表单结构。一个Struts2 web应用程序的控制器组件体现在方法里，这些方法即Java 类。一个方法可以响应来自一个或多个JSP页面的用户输入，每一个方法主要负责验证用户输入并通过调用适当的模型操作来协调事务处理。方法通过一个XML配置文件或者通过Java注解机制来定义和配置。这种配置信息通过确定每个方法后的视图来控制web应用程序流，这取决于方法的结果。Struts2中的核心部分是值栈，值栈是用来存储视图和控制器之间的信息流并在需要的时候进行转换。这消除了许多涉及到处理HTTP请求参数和提供信息给JSP页面来显示的细节。

所有这三个框架在将用户界面组件(视图)与应用程序逻辑(模型)和控制函数(控制器)分离的MVC 模式中是保持一致的。当然，他们在某些方面与原始的MVC又有所不同。

●没有内部的视图->模型的依赖(观察者模式)：web应用程序中的模型组件不会通知视图元素在

模型上发生了那些变化。相反，控制器决定视图的行为取决于模型的事务处理的结果。

●没有一一对应的视图-控制器对应关系：在原来的MVC中，每个视图元素有独立的控制器元

素为了单独的视图元素而定义。

●前端控制器模型：所有这三个框架用了这种模式，单个控制器元素负责响应路由转入的HTTP

请求，根据该请求的URL和配置数据。

●控制器制定视图动态：控制器决定了哪一个视图跟随者每一个控制器方法，基于方法的结果。

这相当于一个本质上是视图=>控制器的依赖。

●控制器元素负责数据验证：交易数据验证本质上是一个模型函数。验证逻辑可以推入到模型

组件，但是负责执行验证函数的仍然是控制器。

●模型没有明确的定义：所有的框架都缺少对模型组件的明确定义。它被假定为包含应用程序

逻辑和数据管理，但是没有明确的结构来定义模型或者将其与控制器干净的分离。

●模型类被实例化的需求：web框架实例化模型对象是由于处理事务的需要以及封装域实体的

需要，而不是出于坚持一个设想的原始的MVC中的模型组件。但是，数据库或者应用程序的数据持续层可以是持久的模型组件。