资源目录
压缩包内文档预览：
编号：6099425
类型：共享资源
大小：50.41KB
格式：RAR
上传时间：2017-11-16
上传人：闰***
认证信息
个人认证
冯**（实名认证）
河南
IP属地：河南
13
积分
- 关 键 词：
-
mvc
设计
模式
中文
- 资源描述：
-
MVC设计模式【中文4230字】,mvc,设计,模式,中文
- 内容简介：
-
【中文 4230 字】MVC 设计模式Ralph F. Grove计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州groverfEray Ozkan计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州ozkanex关键字：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.Net MVC2 是微软 web 开发框架的最新版本(Esposito,2010) 。它为早期的基于 Web Form 的ASP.Net 版本添加了 MVC 设计架构。ASP.Net 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 中的模型组件。但是，数据库或者应用程序的数据持续层可以是持久的模型组件。这些 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. Barrett, R., Delany, S., 2004, openMVC: A Nonproprietary Component-based Framework for Web Applications, WWW2004.2. Chun, L., Yanhua, W., Hanhong, L., 2003, A Novel Web Application Frame Developed by MVC, Software Engineering Notes, 28(2).3. Esposito, D., 2010. Programming Microsoft ASP.NET MVC, Microsoft Press.4. Fowler, M., 2003. Patterns of Enterprise Application Architecture, Addison-Wesley, Boston.5. Gamma, E., Helm, R., Johnson, R., Vlissides, J.,1995. Design Patterns, Addison Wesley, Reading, MA.6. Goldberg, A., Robson, D., 1985. Smalltalk-80 : the language and its implementation, Addison-Wesley.7. Krasner, G.E., Pope, S.T., 1988. A Cookbook for Using the Model-View Controller User Interface Paradigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3), 26-49.8. Mahmoud, Q., 2003. Servlets and JSP Pages Best Practices, /technetwork/articles/javase/servlets-jsp-140445.html.9. Thomas, D., Hansson, D.H., 2007. Agile Web Development with Rails. The Pragmatic Bookshelf.THE MVC-WEB DESIGN PATTERNRalph F. GroveDepartment of Computer Science, James Madison University, Harrisonburg, VA USAgroverfEray OzkanDepartment of Computer Science, James Madison University, Harrisonburg, VA USAozkanexKeywords: web, web framework, design patterns, model view controller patternAbstract: The Model-View-Controller design pattern is cited as the architectural basis for many web development frameworks. However, the version of MVC used for web development has changed as it has evolved from the original Smalltalk MVC. This paper presents an analysis of those changes, and proposes a separate Web-MVC pattern that more accurately describes how MVC is implemented in web frameworks.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 (Goldberg 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 design 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 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 and 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 programming 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 the 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, 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 smaller (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 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 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, primarily 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 design 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 modify 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 version 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 HTTP requests that determines and instantiates an appropriate controller for each request. Controllers 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 requests, 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 objects, 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 element, 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 developed for use with the Ruby programming languages (Thomas and Hansson, 2007). HTTP 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 request 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 management, 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 presentation. 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 provide 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, 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 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 application 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 HTTP request 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 pattern in several respects, however. 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 transaction processing. No 1-1 view-controller correspondence: In the original MVC, each view element has a unique controller element that is defined for that view element alone. The Front Controller pattern: All three frameworks use this pattern, in which a single controller element is responsible for routing incoming HTTP requests, based upon the requested URL and configuration data. 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. Controller elements are responsible for data validation: Transaction parameter validation is essentially a model function. Validation logic can be pushed into the model component, but the responsibility for executing the validation function is still with the controller. The model is not clearly defined: All of the frameworks lack a clear definition of the Model component. 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. Model classes are instantiated on demand.Rather than a persistent model component as envisioned in the original MVC, the web frameworks 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 architectural 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 order 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 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
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号