外文翻译_MVC设计模式

1、MVC设计模式Ralph F. Grove计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州Eray Ozkan计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州ozkanexgmail.关键字：web，web框架，设计模式，模型-视图-控制器模式摘要：模型-视图-控制器模式被引用为许多web开发框架的基础架构。然而，用于web开发的MVC版本随着原来的Smalltalk的MVC的演变而发生了一些改变。本文介绍了对这些变化的分析，并提出了一种独立的Web-MVC模式，用于更准确的描述MVC是如何在web框架中实现的。1.介绍模型-视图-控制器(Modle-V

2、iew-Controller，MVC)设计模式被一些web应用框架作为基础架构，例如ASP.NET，Rails，以与Struts。MVC最初是在施乐帕克研究中心(Goldberg和Robson，1985)开发的Smalltalk编程环境中实现的。为了适应web框架，MVC已经演变成了另一种方式，最终成为一种不同于其他任何设计模式，也与原始的Smaltalk完全不同的模式的实现。本文的第一个目标是介绍MVC设计模式，其中包括它的原始形态(第2节)以与现代众所周知的用于web应用框架的变更后的形态(第3节)。第二个目标是对这个模式演变后发生的变化进行评估，同时呈现演变后版本的有效性(第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)。正如这个名称所暗示的一样，

4、MVC设计模式的功能可以分解为三大部分。模型(model)组件封装了应用程序的特定域的结构和功能，其本质就是包括了应用程序的状态以与改变这种状态的操作。模型还保持着对视图和控制器组件的依赖，当应用程序的状态发生变化时它会有通知。这种行为是观察者模式下的一个实例(Gamma, Helm, Johnson和Vlissides, 1995)。视图(view)组件通过图形用户界面将信息呈现给用户。应用程序中不同的操作会有多个视图，不同的视图呈现给多个用户。视图也有可能是分层的，它由一些更小的(子视图)元素构成。当视图中包含的信息被更新时(通过对信息做出响应的模型组件)视图会得到模型的通知，然后视图会查

5、询模型以获得它所要呈现的信息。控制器(controller)组件通过用户界面响应用户的操作，它负责将事件传递给模型然后执行操作。控制器与视图是一一对应的存在的，多层次的视图也因此在相应的控制器之间复制。当控制器接受到输入信号时，它首先将其传送到活动的子控制器，因此输入信号首先会被最低层级的控制器处理。用户的输入和输出形成了MVC的一个隐含的第四个组件。Smalltalk系统是基于图形显示和标准的用户输入设备，主要是键盘和鼠标。用户菜单被认为是一种虚拟类型的设备，它主要用于传送输入信号给控制器层，就跟键盘和鼠标一样。虽然菜单是在用户图形界面(GUI)中实现的，但是它们不被认为是视图组件。MVC设

6、计模式的主要优点是将关注点分离和由此产生的模块化。这种设计将用户界面的呈现与用户输入的操作隔离了，同时也将这两部分与应用程序的状态和事件处理过程隔离了。这就使得当你修改或替换某一个组件时，无需修改甚至无需解会其他部分。它也可以通过为新的接口介质添加一个视图/控制器的组合，或者通过独立于其他组件为模型添加新的功能而增加其可扩展性。3.WEB框架中的MVCASP.Net MVC2是微软web开发框架的最新版本(Esposito,2010)。它为早期的基于Web Form的ASP.Net版本添加了MVC设计架构。ASP.Net MVC2为 请求使用一个单一的处理程序，为每一个请求确定并实例化一个合适

7、的控制器。控制器负责处理传入的请求，由模型策划事务处理，为后来的视图元素准备数据，同时激活视图元素使其产生响应。一个控制器类可以包含多个用于响应不同请求的方法，每个方法都作为一个独立的公共方法类。视图在ASP文件中被定义，它是一种带有生成动态容的服务器脚本的HTML模板。每一个视图从激活它的控制器那里接收信息，无论是作为本地对象还是视图-模型对象，它都是独立的来自模型的数据的合辑，每一个都是为了特定的视图而设计。模型组件用于包含应用程序的逻辑和数据库访问。视图模型之间有一定的区别，数据结构用于传送信息给一个特定的视图元素，而应用程序模型则是域的实体和对它进行操作的相关事务。模型组件还提供对象关

8、系映射，它隐藏了应用程序域对象映射到数据库表的细节。Rails是一个用于Ruby(Thomas和Hansson, 2007)编程语言开发的web应用程序框架。 请求在Rails过核心路由器来处理，核心路由器将请求转到相应的ActionController类和控制器组件的方法。ActionController对象负责过滤请求参数，通过调用适当的模型元素的方法策划事务，并安排相应的视图响应。ActionController还安排视图元素访问来自模型的数据。控制器控制器元素也负责web会话管理，包括cookie管理。用户界面(视图组件)用过动态的模板文件呈现出来，这些动态模板就是嵌入了Ruby就脚本

9、的标准HTML文档，类似于ASP,PHP,JSP等。视图元素可以在需要的时候访问模型组件并获取数据呈现出来。Rail模型组件包括封装应用程序逻辑的元素和事务处理(ActiveModel)，以与一个映射方案相关的对象(ActiveRecord)，该对象通过模型元素联合了每一个数据库表。模型也包括提供访问访问外部资源的ActiveResource元素。Apache Struts2 框架是基于Java企业版(J2EE)和Java服务器页面( 技术)。Struts2视图组件就是JSP文档，这些文档嵌入了提供多种功能的标签，包括流控制(迭代，条件句)，访问Java Bean(模型组件)，以与简化HTML

10、表单结构。一个Struts2 web应用程序的控制器组件体现在方法里，这些方法即Java类。一个方法可以响应来自一个或多个JSP页面的用户输入，每一个方法主要负责验证用户输入并通过调用适当的模型操作来协调事务处理。方法通过一个XML配置文件或者通过Java注解机制来定义和配置。这种配置信息通过确定每个方法后的视图来控制web应用程序流，这取决于方法的结果。Struts2中的核心部分是值栈，值栈是用来存储视图和控制器之间的信息流并在需要的时候进行转换。这消除了许多涉与到处理 请求参数和提供信息给JSP页面来显示的细节。所有这三个框架在将用户界面组件(视图)与应用程序逻辑(模型)和控制函数(控制器

11、)分离的MVC模式中是保持一致的。当然，他们在某些方面与原始的MVC又有所不同。l 没有部的视图->模型的依赖(观察者模式)：web应用程序中的模型组件不会通知视图元素在模型上发生了那些变化。相反，控制器决定视图的行为取决于模型的事务处理的结果。l 没有一一对应的视图-控制器对应关系：在原来的MVC中，每个视图元素有独立的控制器元素为了单独的视图元素而定义。l 前端控制器模型：所有这三个框架用了这种模式，单个控制器元素负责响应路由转入的 请求，根据该请求的URL和配置数据。l 控制器制定视图动态：控制器决定了哪一个视图跟随者每一个控制器方法，基于方法的结果。这相当于一个本质上是视图=&g

12、t;控制器的依赖。l 控制器元素负责数据验证：交易数据验证本质上是一个模型函数。验证逻辑可以推入到模型组件，但是负责执行验证函数的仍然是控制器。l 模型没有明确的定义：所有的框架都缺少对模型组件的明确定义。它被假定为包含应用程序逻辑和数据管理，但是没有明确的结构来定义模型或者将其与控制器干净的分离。l 模型类被实例化的需求：web框架实例化模型对象是由于处理事务的需要以与封装域实体的需要，而不是出于坚持一个设想的原始的MVC中的模型组件。但是，数据库或者应用程序的数据持续层可以是持久的模型组件。这些MVC模式的变化反映了客户端-服务器架构风格的基本性质优先于Web。视图平台(客户端)被物理地与

13、其他组件分离开，因此视图组件在结构与操作方面与控制器和模型变得不那么紧密。同时，视图承担了一些模型的任务以便提供一个更具响应式的用户界面。控制新增加的任务(前端控制器的函数和视图测序)是必须的，因为需要显示的管理固有的用户体验控制流。4.MVC-WEB设计模式MVC-Web设计模式在这一节中描述了一个MVC模式中的模型在web应用程序框架中是如何被解释的。MVC-Web反映了MVC设计模式已经在web框架中实现了的革命性的变化。MVC-Web模型组件同程负责保留应用程序的状态。它的职责包括：l 数据呈现：维护一个数据库或一个抽象的数据接口l 事务处理：执行在应用程序状态上操作的的程序逻辑l 外

14、部接口：管理与外部代理的互动，例如web服务或者遗留系统l 查询处理：为视图和控制器在响应查询是提供信息MVC-Web视图组件呈现了用户界面，包括数据呈现和输入设备。它的职责包括：l 信息检索和显示：呈现信息给用户；必要时查询模型以获得信息用来显示l 用户输入：呈现输入表单和允许用户与程序交互的控件l 客户端动态行为：为用户提供交互式的客户端体验(用JavaScript,Ajax,或者其他方式)；这可能包含输入实现，输入验证或其他应用程序特定规则和函数的实现，否则这将由模型来完成。MVC-Web控制器组件有三个主要职责：l 前端控制器：接受传入的请求并把它们路由到相应的处理程序l 方法处理：接

15、受请求参数；验证请求参数的语法(这可能通过视图元素进行了重复验证)；通过调用模型元素来编排请求的处理程序l 控制流：调用相应的视图元素作为一个对请求正在被处理的响应，根据方法的结果来调用。MVC-Web模式的组件之间的交互有以下方式：l 模型-视图：视图元素会查询模型以获取信息用来显示给用户l 模型-控制器：控制器方法元素要求模型元素传送请求交易。模型函数可以包括执行程序逻辑，更新数据库，以与调用外部代理的服务。控制器元素会从模型请求数据并传递给视图元素l 控制器-视图：控制器元素对来自视图元素的请求做出响应。控制器也决定了哪一个视图元素会被呈现给用户以响应请求。控制器会通过视图元素为用户准备

16、信息。这个版本的MVC不同于原始版本(Smalltalk)有以下几几个重要方面：l 观察者模式不是用来吧模型的更新通知给视图和控制器。控制器具有更突出的作用而不是用来传播更新l 视图和控制器之间没有一对一的对于关系了。现在已经是多对多的关系了。l 控制器必须能够从多个视图元素(前端控制模式)那里路由请求并能管理程序在响应中的流。控制器作为这个功能的一部分可能会从模型传送信息给视图。l 同样的程序逻辑(例如验证或者数据输入完成)可以被呈现在视图和控制器组件。这个可能分离的关注点，但是通过给用户提供更快的响应来提高了应用程序的效率。这个MVC-Web模式是为了反映当前的MVC在web应用程序中的实

17、现。模式不要求稳定，然而，MVC-Web模式的改进一直在继续，例如在基于Ajax的用户界面中变得更加丰富更具响应效果。这些改变也许会模糊MVC-Web各个组件之间的界限并且降低这种模式提供的模块化的程度。参考1. Barrett, R., Delany, S., 2004, openMVC: A NonproprietaryComponent-based Framework for WebApplications, WWW2004.2. Chun, L., Yanhua, W., Hanhong, L., 2003, A Novel WebApplication Frame Developed

18、 by MVC, SoftwareEngineering Notes, 28(2).3. Esposito, D., 2010. Programming Microsoft ASP.NETMVC, Microsoft Press.4. Fowler, M., 2003. Patterns of Enterprise ApplicationArchitecture, Addison-Wesley, Boston.5. Gamma, E., Helm, R., Johnson, R., Vlissides, J.,1995.Design Patterns, Addison Wesley, Read

19、ing, MA.6. Goldberg, A., Robson, D., 1985. Smalltalk-80 : thelanguage and its implementation, Addison-Wesley.7. Krasner, G.E., Pope, S.T., 1988. A Cookbook for Usingthe Model-View Controller User Interface Paradigm inSmalltalk-80. Journalof Object-OrientedProgramming, 1(3), 26-49.8. Mahmoud, Q., 200

20、3. Servlets and JSP Pages BestPractices, .oracle./technetwork/articles/javase/servlets-jsp-140445.html.9. Thomas, D., Hansson, D.H., 2007. Agile WebDevelopment with Rails. The Pragmatic Bookshelf.THE MVC-WEB DESIGN PATTERNRalph F. GroveDepartment of Computer Science, James Madison University, Harris

21、onburg, VA USAEray OzkanDepartment of Computer Science, James Madison University, Harrisonburg, VA USAozkanexgmail.Keywords: web, web framework, design patterns, model view controller patternAbstract: The Model-View-Controller design pattern is cited as the architectural basis for many

22、 web developmentframeworks.However, the version of MVC used for web development has changed as it has evolved fromthe original Smalltalk MVC. This paperpresents an analysis of those changes, and proposes a separateWeb-MVC pattern that more accurately describes how MVC isimplemented in web frameworks

23、.1 INTRODUCTION The Model-View-Controller (MVC) design pattern is cited as the basis for the architecture of several web application frameworks, such as ASP .Net, Rails, and Struts. The MVC pattern was originally implemented in the Smalltalk-80 programming environment developed at Xerox PARC (G

24、oldberg and Robson, 1985). As it has been adapted for web frameworks the MVC pattern has evolved in different ways, resulting in implementations that differ significantly from each other and from the original Smalltalk implementation.  The first goal of this paper is to present the MVC des

25、ign pattern, both in its original form (section 2) and the variations currently used in well-known web application frameworks (section 3). Second, we present an evaluation of the changes in the pattern as it has evolved and the effectiveness of the evolved version (section 3). Finally, we propose a

26、standard MVC-Web design pattern description that reflects the current use of the pattern in web frameworks while maintaining the original desirable qualities of MVC (section 4).Revisions of the MVC-based web application framework design have been proposed (Chun, Yanhua, and Hanhong, 2003) (Barrett a

27、nd Delaney, 2004).  This paper, however, does not propose a new MVC architecture, rather it analyzes and documents the evolution of the MVC pattern as it was adapted from Smalltalk to web frameworks. 2 SMALLTALK MVC The MVC design pattern was introduced with the Smalltalk program

28、ming environment as a way to structure interactive applications in a modular fashion (Krasner and Pope, 1988). As the name implies, the MVC design pattern decomposes functionality into three major components. The model component encapsulates the domain-specific structure and functionality of th

29、e application. This essentially includes the state of the application and operations that can change state. The model also maintains dependencies of view and controller components, which it notifies in the event of changes in state. This behavior is an instance of the Observer pattern (Gamma, Helm,

30、Johnson and Vlissides, 1995). The view component presents information to the user through a graphical user interface. There may be multiple views of different types operating within the application, presenting different views to multiple users. Views may also be hierarchical, constructed from smalle

31、r (subview) elements. When information contained in a view is updated (by a model component that is responsible for that information) the view is notified by the model and then the view may query the model to obtain information that it needs to present. The controller component responds to user

32、 actions via the user interface. It is responsible for passing transactions to the model for execution. Controllers exist in a one-to-one correspondence with views. The hierarchy of views is therefore also replicated among the corresponding controllers. When a controller receives input, it yields to

33、 its active subcontrollers first, so that input is processed at the lowest levels of the controller hierarchy first. User input and output devices form an implicit fourth component of the MVC pattern. The Smalltalk system was based on a graphical display and standard user input devices, primari

34、ly a keyboard and mouse. User menus were also considered to be a type of virtual device that transmitted input to the controller hierarchy just as the keyboard or mouse did. Though menus were implemented in the GUI, they were not considered as view components. The primary benefit of the MVC des

35、ign pattern is separation of concerns and the resulting modularity. The design isolates user interface presentation from user input handling, and isolates both of these from application state and transaction processing. This makes it possible to modify or replace one component without needing to mod

36、ify or even understand the others. It also facilitates extensibility by making it possible to add a view/controller pair for a new interface medium, or to add new functionality to the model independently of the other components.  3 MVC IN WEB FRAMEWORKS ASP .Net MVC 2 is the latest ve

37、rsion of the Microsoft web development framework (Esposito, 2010). It adds the MVC design architecture to earlier versions of ASP .Net based on Web Forms. The ASP .Net MVC 2 framework uses a single handler for requests that determines and instantiates an appropriate controller for each request. Cont

38、rollers are responsible for handling incoming requests, orchestrating transaction processing by the model, preparing data for the subsequent view element, and activating that view element to generate the response. A controller class can include multiple actions that respond to different types of req

39、uests, each action being a unique public method of the class. Views are defined in ASP files, which are HTML templates with server-side scripts that can generate dynamic content. Each view receives information from the controller that activated it, either as native objects or as view-model obje

40、cts, which are unique compilations of data from the model, each designed for a specific view. The model component is intended to contain application logic and database access. A differentiation is made between view models, which are data structures intended to convey information to a specific view e

41、lement, and application models, which are domain entities and related transactions that operate on them. The model component also provides object-relational mapping, which hides the details of how application domain objects are mapped to database tables. Rails is a web application framework dev

42、eloped for use with the Ruby programming languages (Thomas and Hansson, 2007). requests are handled in Rails through a central router that directs requests to the appropriate ActionController class and method within the controller component. ActionController objects are responsible for filtering req

43、uest parameters, for orchestrating transactions by invoking methods of appropriate model elements, and for arranging the appropriate view response. ActionControllers also arrange for view elements to have access to data from the model. The controller elements are also responsible for web session man

44、agement, including cookie management. The user interface (view component) is presented through dynamic document templates that are standard HTML documents with embedded Ruby scripts, similar to ASP, PHP, JSP, etc.  View elements can access the model component as necessary to obtain data for pre

45、sentation. The Rails model component includes elements that encapsulate application logic and transaction processing (ActiveModel), and an object relational mapping scheme (ActiveRecord) that associates each database table with a model element. The model also includes ActiveResource elements that pr

46、ovide access to external resources.  The Apache Struts 2 framework is based on Java 2 Enterprise Edition (J2EE) and Java Server Pages (JSP) technology. Struts2 view components are JSP documents with embedded tags that provide a variety of functionality, including flow of control (iteration

47、, conditionals), access to Java Beans (model components), and streamlined HTML Forms construction. Controller components of a Struts2 web application are embodied in actions, which are Java classes. An action can respond to user input from one or more JSPs. The primary responsibilities of each

48、action are to validate user input and to orchestrate transaction processing by invoking appropriate model operations.  Actions are defined and configured through an XML configuration file or through the Java annotation mechanism. This configuration information also controls the flow of a web ap

49、plication by determining what view follows each action, depending upon the outcome of the action. A central part of Struts2 is the Value Stack, where information flowing between view and controller is stored and converted as needed. This eliminates much of the detail involved in handling reques

50、t parameters and in providing information for JSPs to display.  All three of these web frameworks are consistent with the MVC pattern in that user interface components (View) are separated from application logic (Model) and control functions (Controller). They differ from the original MVC

51、pattern in several respects, however. l §§ No inherent view->model dependency (Observer pattern): The model component in web applications does not notify view elements of changes to the model. Rather, the controller determines view behavior, depending on the outcome of model transa

52、ction processing. l §No1-1view-controllercorrespondence:IntheoriginalMVC,eachviewelementhasauniquecontrollerelementthatisdefinedforthatviewelementalone.l §TheFrontControllerpattern:Allthreeframeworksusethispattern,inwhichasinglecontrollerelementisresponsibleforroutinginingrequests,basedupo

53、ntherequestedURLandconfigurationdata.l §The controller specifies view dynamics: The controller decides which view follows each controller action, based upon the action outcome. This amounts to what is essentially a view=>controller dependency. l §Controllerelementsareresponsiblefordatav

54、alidation:Transactionparametervalidationisessentiallyamodelfunction.Validationlogiccanbepushedintothemodelponent,buttheresponsibilityforexecutingthevalidationfunctionisstillwiththecontroller.l §The model is not clearly defined: All of the frameworks lack a clear definition of the Model componen

55、t. It is assumed to involve application logic and data management, but there is no clear structure to define the model or to cleanly separate it from the controller. l §Modelclasses are instantiated on demand.Rather than a persistent model component as envisioned in the original MVC, the web fr

56、ameworks instantiate model objects as needed to handle transactions and to encapsulate domain entities. The database or data persistence layer of the application can be a persistent model component, however. These changes to the MVC pattern reflect the fundamental nature of the client-server archite

57、ctural style underlying the Web. The view platform (client) is physically separated from the other components, and so the view component has become less closely tied to the controller and model in structure and operation. At the same time, the view has taken on some of the model responsibility in or

58、der to provide a more responsive user interface. The added responsibility of the controller (front controller functions and view sequencing) are necessary because of the need to explicitly manage the flow of control inherent in the user experience. 4 MVC-WEB DESIGN PATTERN The MVC-Web design pattern

59、 described in this section is a model for how the MVC pattern is now being interpreted in web application frameworks. MVC-Web reflects the evolutionary changes that have occurred in the MVC design pattern as it has been implemented in web frameworks. The MVC-Web model component is generally responsible for maintaining the application state. Its responsibilities include: l §Datapersistence:maintainadatabaseoranabstractdatabaseinterfacel §Transactionprocessing:executeapplicationlogicthatoperatesontheapplicationstatel §Externalinterfa