MVC设计模式-外文翻译

MVC设计模式

RalphF. Grove
计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州groverf@jmu.edu

ErayOzkan
计算机科学，詹姆斯麦迪逊大学，哈里森堡，美国弗吉尼亚州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中的MVC

MVC设计模式是随着Smalltalk的编程环境而引入的，从此我们可以以模块化的方式来构建交互

式应用程序(Krasner和Pope,1988)。正如这个名称所暗示的一样，MVC设计模式的功能可以分解为

三大部分。

模型(model)组件封装了应用程序的特定域的结构和功能，其本质就是包括了应用程序的状态以

及改变这种状态的操作。模型还保持着对视图和控制器组件的依赖，当应用程序的状态发生变化时它

会有通知。这种行为是观察者模式下的一个实例(Gamma,Helm, Johnson和Vlissides,1995)。视图(view)

组件通过图形用户界面将信息呈现给用户。应用程序中不同的操作会有多个视图，不同的视图呈现给

多个用户。视图也有可能是分层的，它由一些更小的(子视图)元素构成。当视图中包含的信息被更新

时(通过对信息做出响应的模型组件)视图会得到模型的通知，然后视图会查询模型以获得它所要呈现

的信息。控制器(controller)组件通过用户界面响应用户的操作，它负责将事件传递给模型然后执行操

作。控制器与视图是一一对应的存在的，多层次的视图也因此在相应的控制器之间复制。当控制器接

受到输入信号时，它首先将其传送到活动的子控制器，因此输入信号首先会被最低层级的控制器处理。

用户的输入和输出形成了MVC的一个隐含的第四个组件。Smalltalk系统是基于图形显示和标准

的用户输入设备，主要是键盘和鼠标。用户菜单被认为是一种虚拟类型的设备，它主要用于传送输入

信号给控制器层，就跟键盘和鼠标一样。虽然菜单是在用户图形界面(GUI)中实现的，但是它们不被

认为是视图组件。

MVC设计模式的主要优点是将关注点分离和由此产生的模块化。这种设计将用户界面的呈现与

用户输入的操作隔离了，同时也将这两部分与应用程序的状态和事件处理过程隔离了。这就使得当你

修改或替换某一个组件时，无需修改甚至无需解会其他部分。它也可以通过为新的接口介质添加一个

视图/控制器的组合，或者通过于其他组件为模型添加新的功能而增加其可扩展性。

3.WEB框架中的MVC

ASP.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. Barrett,R., Delany, S., 2004, openMVC: A Nonproprietary Component-basedFramework for Web Applications, WWW2004.

2. Chun,L., Yanhua, W., Hanhong, L., 2003, A Novel Web Application FrameDeveloped by MVC, SoftwareEngineeringNotes,28(2).

3. Esposito,D., 2010. ProgrammingMicrosoft ASP.NET MVC,Microsoft Press.

4. Fowler,M., 2003. Patternsof Enterprise Application Architecture,Addison-Wesley, Boston.

5. Gamma,E., Helm, R., Johnson, R., Vlissides, J.,1995. DesignPatterns,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-ViewController User Interface Paradigm in Smalltalk-80. Journalof

Object-OrientedProgramming,1(3), 26-49.

8. Mahmoud,Q., 2003. Servletsand JSP Pages Best Practices,http://www.oracle.com/technetwork/articles/javase/servlets-jsp-140445.html.

9. Thomas,D., Hansson, D.H., 2007. AgileWeb Development with Rails.The Pragmatic Bookshelf.

THEMVC-WEB DESIGN PATTERN

RalphF. Grove
Departmentof Computer Science, James Madison University, Harrisonburg, VA USA

groverf@jmu.edu
ErayOzkan
Departmentof Computer Science, James Madison University, Harrisonburg, VA USA

ozkanex@gmail.com

Keywords:web, web framework, design patterns, model view controller pattern

Abstract:The Model-View-Controller design pattern is cited as thearchitectural basis for many web development frameworks. However, the

versionof MVC used for web development has changed as it has evolved fromthe original Smalltalk MVC. This paper presents an analysis of

thosechanges, and proposes a separate Web-MVC pattern that more accuratelydescribes how MVC is implemented in web frameworks.

1INTRODUCTION
TheModel-View-Controller (MVC) design pattern is cited as the basis forthe architecture of several web application frameworks, such as ASP.Net, Rails, and Struts. The MVC pattern was originally implementedin the Smalltalk-80 programming environment developed at Xerox PARC(Goldberg and Robson, 1985). As it has been adapted for webframeworks the MVC pattern has evolved in different ways, resultingin implementations that differ significantly from each other and fromthe original Smalltalk implementation.

Thefirst goal of this paper is to present the MVC design pattern, bothin its original form (section 2) and the variations currently used inwell-known web application frameworks (section 3). Second, we presentan evaluation of the changes in the pattern as it has evolved and theeffectiveness of the evolved version (section 3). Finally, we proposea standard MVC-Web design pattern description that reflects thecurrent use of the pattern in web frameworks while maintaining theoriginal desirable qualities of MVC (section 4).

Revisionsof the MVC-based web application framework design have been proposed(Chun, Yanhua, and Hanhong, 2003) (Barrett and Delaney, 2004). Thispaper, however, does not propose a new MVC architecture, rather itanalyzes and documents the evolution of the MVC pattern as it wasadapted from Smalltalk to web frameworks.

2SMALLTALK MVC
TheMVC design pattern was introduced with the Smalltalk programmingenvironment as a way to structure interactive applications in amodular fashion (Krasner and Pope, 1988). As the name implies, theMVC design pattern decomposes functionality into three majorcomponents.

Themodel component encapsulates the domain-specific structure andfunctionality of the application. This essentially includes the stateof the application and operations that can change state. The modelalso maintains dependencies of view and controller components, whichit notifies in the event of changes in state. This behavior is aninstance of the Observer pattern (Gamma, Helm, Johnson and Vlissides,1995). The view component presents information to the user through agraphical user interface. There may be multiple views of differenttypes operating within the application, presenting different views tomultiple users. Views may also be hierarchical, constructed fromsmaller (subview) elements. When information contained in a view isupdated (by a model component that is responsible for thatinformation) the view is notified by the model and then the view mayquery the model to obtain information that it needs to present. Thecontroller component responds to user actions via the user interface.It is responsible for passing transactions to the model forexecution. Controllers exist in a one-to-one correspondence withviews. The hierarchy of views is therefore also replicated among thecorresponding controllers. When a controller receives input, ityields to its active subcontrollers first, so that input is processedat the lowest levels of the controller hierarchy first.

Userinput and output devices form an implicit fourth component of the MVCpattern. The Smalltalk system was based on a graphical display andstandard user input devices, primarily a keyboard and mouse. Usermenus were also considered to be a type

ofvirtual device that transmitted input to the controller hierarchyjust as the keyboard or mouse did. Though menus were implemented inthe GUI, they were not considered as view components.

Theprimary benefit of the MVC design pattern is separation of concernsand the resulting modularity. The design isolates user interfacepresentation from user input handling, and isolates both of thesefrom application state and transaction processing. This makes itpossible to modify or replace one component without needing to modifyor even understand the others. It also facilitates extensibility bymaking it possible to add a view/controller pair for a new interfacemedium, or to add new functionality to the model independently of theother components.

3MVC IN WEB FRAMEWORKS
ASP.Net MVC 2 is the latest version of the Microsoft web developmentframework (Esposito, 2010). It adds the MVC design architecture toearlier versions of ASP .Net based on Web Forms. The ASP .Net MVC 2framework uses a single handler for HTTP requests that determines andinstantiates an appropriate controller for each request. Controllersare responsible for handling incoming requests, orchestratingtransaction processing by the model, preparing data for thesubsequent view element, and activating that view element to generatethe response. A controller class can include multiple actions thatrespond to different types of requests, each action being a uniquepublic method of the class. Views are defined in ASP files, which
areHTML templates with server-side scripts that can generate dynamiccontent. Each view receives information from the controller thatactivated it, either as native objects or as view-model objects,which are unique compilations of data from the model, each designedfor a specific view. The model component is intended to containapplication logic and database access. A differentiation is madebetween view models, which are data structures intended to conveyinformation to a specific view element, and application models, whichare domain entities and related transactions that operate on them.The model component also provides object-relational mapping, whichhides the details of how application domain objects are mapped todatabase tables.

Railsis a web application framework developed for use with the Rubyprogramming languages (Thomas and Hansson, 2007).

HTTPrequests are handled in Rails through a central router that directsrequests to the appropriate ActionController class and method withinthe controller component. ActionController objects are responsiblefor filtering request parameters, for orchestrating transactions byinvoking methods of appropriate model elements, and for arranging theappropriate view response.

ActionControllersalso arrange for view elements to have access to data from the model.The controller elements are also responsible for web sessionmanagement, including cookie management. The user interface (viewcomponent) is presented through dynamic document templates that arestandard HTML documents with embedded Ruby scripts, similar to ASP,PHP, JSP, etc. View elements can access the model component asnecessary to obtain data for presentation. The Rails model componentincludes elements that encapsulate application logic and transactionprocessing (ActiveModel), and an object relational mapping scheme(ActiveRecord) that associates each database table with a modelelement. The model also includes ActiveResource elements that provideaccess to external resources.

TheApache Struts 2 framework is based on Java 2 Enterprise Edition(J2EE) and Java Server Pages (JSP) technology. Struts2 viewcomponents are JSP documents with embedded tags that provide avariety of functionality, including flow of control (iteration,conditionals), access to Java Beans (model components), andstreamlined HTML Forms construction. Controller components of aStruts2 web application are embodied in actions, which are Javaclasses. An action can respond to user input from one or more JSPs.The primary responsibilities of each action are to validate userinput and to orchestrate transaction processing by invokingappropriate model operations. Actions are defined and configuredthrough an XML configuration file or through the Java annotationmechanism. This configuration information also controls the flow of aweb application by
determiningwhat view follows each action, depending upon the outcome of theaction. A central part of Struts2 is the Value Stack, whereinformation flowing between view and controller is stored andconverted as needed. This eliminates much of the detail involved inhandling HTTP request parameters and in providing information forJSPs to display.

Allthree of these web frameworks are consistent with the MVC pattern inthat user interface components (View) are separated from applicationlogic (Model) and control functions (Controller). They differ fromthe original MVC pattern in several respects, however.

 No inherent view->model dependency (Observer pattern): The modelcomponent in web applications does not notifyview elements of changes to the model. Rather, the controllerdetermines view behavior, depending on the outcomeof model transaction processing.

 No 1-1 view-controller correspondence: In the original MVC, each viewelement has a unique controller element that

isdefined for that view element alone.

 The Front Controller pattern: All three frameworks use this pattern,in which a single controller element is responsiblefor routing incoming HTTP requests, based upon the requested URL andconfiguration data.

 The controller specifies view dynamics: The controller decides whichview follows each controller action, based uponthe action outcome. This amounts to what is essentially a view=>controller dependency.

 Controllerelements are responsible for data validation: Transaction parametervalidation is essentially a model 
function.Validation logic can be pushed into the model component, but theresponsibility for executing the validation function is still withthe controller.

 The model is not clearly defined: All of the frameworks lack a cleardefinition of the Model component. It is assumedto involve application logic and data management, but there is noclear structure to define the model or to cleanlyseparate it from the controller.

 Modelclasses are instantiated on demand.Rather than a persistent modelcomponent as envisioned in the original 
MVC,the web frameworks instantiate model objects as needed to handletransactions and to encapsulate domain entities. The database or datapersistence layer of the application can be a persistent modelcomponent, however.

Thesechanges to the MVC pattern reflect the fundamental nature of theclient-server architectural style underlying the Web. The viewplatform (client) is physically separated from the other components,and so the view component has become less closely tied to thecontroller and model in structure and operation. At the same time,the view has taken on some of the model responsibility in order toprovide a more responsive user interface. The added responsibility ofthe controller (front controller functions and view sequencing) arenecessary because of the need to explicitly manage the flow ofcontrol inherent in the user experience.

4MVC-WEB DESIGN PATTERN
TheMVC-Web design pattern described in this section is a model for howthe MVC pattern is now being interpreted in web applicationframeworks. MVC-Web reflects the evolutionary changes that haveoccurred in the MVC design pattern as it has been implemented in webframeworks.

TheMVC-Web model component is generally responsible for maintaining theapplication state. Its responsibilities include:  Data persistence: maintain a database or an abstract databaseinterface
Transaction processing: execute application logic that operates onthe application state 
 External interface: manage interactions with external agents, such asweb services or legacy systems  Query handling: provide information to view and controller elementsin response to queries.

TheMVC-Web view component presents a user interface, including datapresentation and input devices. Its responsibilities include:
Information retrieval and display: present information to the user;query the model as necessary to obtain information 
tobe displayed
 User input: present input forms and controls that allow the user tointeract with the application

Client-side dynamic behavior: provide an interactive client-sideexperience for the user (using JavaScript, Ajax, or othermeans); This may include input completion, input validation or otherimplementations of application-specific rulesor functions that are otherwise a responsibility of the modelcomponent.

TheMVC-Web controller component has three primary responsibilities.

 Front controller: receive incoming requests and route them to theappropriate handler
 Action handlers: receive request parameters; validate requestparameter syntax (this may repeat validation done by viewelements); orchestrate request handling by invoking appropriate modelelements
 Control flow: invoke the appropriate view element as a response tothe request being processed, depending upon the outcomeof the action invoked.

Componentsof the MVC-Web pattern interact in the following ways.

 Model-view: View elements may query the model to obtain informationto be displayed to the user
 Model-controller: Controller action elements call on model elementsto carry out requested transactions. Model functionscan include executing application logic, updating the database, orinvoking services of external agents.

Controllerelements may request data from the model to be passed to viewelements.

 Controller-view: Controller elements respond to requests originatingwith view elements. The controller also determineswhich view element will be presented to the user in response to arequest. Controller elements may prepare informationfor use by view elements.

Thisversion of MVC differs from the original (Smalltalk) version inseveral important ways:
 The Observer pattern is not used to inform the view and controller ofmodel updates. The controller has a more prominentrole instead in propagating updates.

 There is no 1-1 correspondence between view and controller elements.The relationship is many-many instead.

 The controller must be able to route requests from multiple viewelements (Front Controller pattern) and to manage theflow of the application in response. The controller may passinformation from model to view as part of this function.

 Some application logic (e.g., for validation or completion of inputdata) can be present in the view and controller components.This muddies the separation of concerns, but improves efficiency ofthe application by providing faster responseto users.

ThisMVC-Web pattern is intended to reflect the current implementation ofMVC in web application frameworks. The pattern is not necessarilystable, however. Evolution of the MVC-Web pattern continues, forexample in Ajax-based user interfaces that are becoming richer andmore responsive. Such changes may further cloud the boundariesbetween MVC-Web components and reduce the degree of modularity thatthe pattern provides.

REFERENCES
1. Barrett,R., Delany, S., 2004, openMVC: A Nonproprietary Component-basedFramework for Web Applications, WWW2004.

2. Chun,L., Yanhua, W., Hanhong, L., 2003, A Novel Web Application FrameDeveloped 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 itsimplementation, Addison-Wesley.

7. Krasner,G.E., Pope, S.T., 1988. A Cookbook for Using the Model-ViewController User Interface Paradigm in Smalltalk-80. Journal of

Object-OrientedProgramming, 1(3), 26-49.

8. Mahmoud,Q., 2003. Servlets and JSP Pages Best Practices,http://www.oracle.com/technetwork/articles/javase/servlets-jsp-140445.html.

9. Thomas,D., Hansson, D.H., 2007. Agile Web Development with Rails. ThePragmatic Bookshelf.