外文翻译-MVC设计模式

MVC设计模式

Ralph F. Grove

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

groverf@https://www.360docs.net/doc/c38506909.html,

ErayOzkan

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

ozkanex@https://www.360docs.net/doc/c38506909.html,

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

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

1.介绍

模型-视图-控制器(Modle-View-Controller，MVC)设计模式被一些web应用框架作为基础架构，例如https://www.360docs.net/doc/c38506909.html,，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

https://www.360docs.net/doc/c38506909.html, MVC2是微软web开发框架的最新版本(Esposito,2010)。它为早期的基于Web Form的https://www.360docs.net/doc/c38506909.html,版本添加了MVC设计架构。https://www.360docs.net/doc/c38506909.html, 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 NonproprietaryComponent-based Framework for WebApplications, WWW2004.

2. Chun, L., Yanhua, W., Hanhong, L., 2003, A Novel WebApplication Frame Developed by MVC, SoftwareEngineering Notes,

28(2).

3. Esposito, D., 2010. Programming Microsoft https://www.360docs.net/doc/c38506909.html,MVC, 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, Reading, 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., 2003. Servlets and JSP Pages BestPractices,

https://www.360docs.net/doc/c38506909.html,/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 PATTERN

Ralph F. Grove

Department of Computer Science, James Madison University, Harrisonburg, VA USA

groverf@https://www.360docs.net/doc/c38506909.html,

ErayOzkan

Department of Computer Science, James Madison University, Harrisonburg, VA USA

ozkanex@https://www.360docs.net/doc/c38506909.html,

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

Abstract: The Model-View-Controller design pattern is cited as the architectural basis for many 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.

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 cla sses 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 component is generally responsible for maintaining the application state. Its responsibilities include:

● Data persistence: maintain a database or an abstract database interface

● Transaction processing: execute application logic that operates on the application state

● External interface: manage interactions with external agents, such as web services or legacy

systems

● Query handling: provide i n formation to view and controller elements in response to queries.

The MVC-Web view component presents a user interface, including data presentation and input devices. Its responsibilities include:

● Information retrieval and display: present information to the user; query the model as necessary to

obtain information to be displayed

● User input: present input forms and controls that allow the user to interact with the application

● Client-side dynamic behavior: provide an interactive client-side experience for the user (using

JavaScript, Ajax, or other means); This may include input completion, input validation or other

implementations of application-specific rules or functions that are otherwise a responsibility of the

model component.

The MVC-Web controller component has three primary responsibilities.

● Front controller: receive incoming requests and route them to the appropriate handler

● Action handlers: receive request parameters; validate request parameter syntax (this may repeat

validation done by view elements); orchestrate request handling by invoking appropriate model

elements

● Control flow: invoke the appropriate view element as a response to the request being processed,

depending upon the outcome of the action invoked.

Components of the MVC-Web pattern interact in the following ways.

● Model-view: View elements may query the model to obtain information to be displayed to the user

● Model-controller: Controller action elements call on model elements to carry out requested

transactions. Model functions can include executing application logic, updating the database, or

invoking services of external agents. Controller elements may request data from the model to be

passed to view elements.

● Controller-view: Controller elements respond to requests originating with view elements. The

controller also determines which view element will be presented to the user in response to a request.

Controller elements may prepare information for use by view elements.

This version of MVC differs from the original (Smalltalk) version in several important ways:

● The Observer pattern is not used to inform the view and controller of model updates. The

controller has a more prominent role 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 view elements (Front Controller

pattern) and to manage the flow of the application in response. The controller may pass information from model to view as part of this function.

Some application logic (e.g., for validation or completion of input data) can be present in the view and controller components. This muddies the separation of concerns, but improves efficiency of the application by providing faster response to users.

This MVC-Web pattern is intended to reflect the current implementation of MVC in web application frameworks. The pattern is not necessarily stable, however. Evolution of the MVC-Web pattern continues, for example in Ajax-based user interfaces that are becoming richer and more responsive. Such changes may further cloud the boundariesbetween MVC-Web components and reduce the degree of modularity that the pattern provides.

REFERENCES

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 https://www.360docs.net/doc/c38506909.html, 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,

https://www.360docs.net/doc/c38506909.html,/technetwork/articles/javase/servlets-jsp-140445.html.

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