View source for Model–view–controller

{{Short description|Software design pattern}}
[[File:MVC-Process.svg|right|200px|thumb|Diagram of interactions in MVC's Smalltalk-80 interpretation]]

'''Model–view–controller''' ('''MVC''') is a software [[architectural pattern]]<ref>{{Cite web|url=https://www.youtube.com/watch?v=o_TH-Y78tt4&t=1667|title = The Principles of Clean Architecture by Uncle Bob Martin|website = [[YouTube]]| date=15 December 2015 }}</ref> commonly used for developing [[user interface]]s that divides the related program logic into three interconnected elements. These elements are:
* the '''[[model]]''', the internal representations of information
* the '''view''', the interface that presents information to and accepts it from the user
* the '''controller''', the software linking the two.<ref name = "Reenskaug and Coplien, Artima, 2009" >{{ Cite web | url = https://www.artima.com/articles/dci_vision.html | title = The DCI Architecture: A New Vision of Object-Oriented Programming | access-date = 3 August 2019 | quote = More deeply, the framework exists to separate the representation of information from user interaction. | first1 = Trygve | last1 = Reenskaug | first2 = James O. | last2 = Coplien | date = 20 March 2009 |website = Artima Developer | archive-url = https://web.archive.org/web/20090323032904/https://www.artima.com/articles/dci_vision.html | archive-date = 23 March 2009 | df = dmy-all }}</ref><ref>Burbeck (1992): "... the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object."</ref>

Traditionally used for desktop [[graphical user interface]]s (GUIs), this pattern became popular for designing [[web application]]s.<ref>{{Cite news|url=http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/|title=What Are The Benefits of MVC?|last=Davis|first=Ian|newspaper=Internet Alchemy|access-date=2016-11-29}}</ref> Popular programming languages have MVC frameworks that facilitate the implementation of the pattern.

__TOC__

==History==
One of the seminal insights in the early development of graphical user interfaces, MVC became one of the first approaches to describe and implement software constructs in terms of their [[Single responsibility principle|responsibilities]].<ref>[http://c2.com/cgi/wiki?ModelViewControllerHistory Model–View–Controller History]. C2.com (2012-05-11). Retrieved on 2013-12-09.</ref>

[[Trygve Reenskaug]] created MVC while working on [[Smalltalk]]-79 as a visiting scientist at the Xerox [[PARC (company)|Palo Alto Research Center]] (PARC) in the late 1970s.<ref name="page_trygver">[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Notes and Historical documents] from Trygve Reenskaug, inventor of MVC.</ref><ref name="notes1">"A note on DynaBook requirements", Trygve Reenskaug, 22 March 1979, [https://wayback.archive-it.org/10370/20180425072145/http://folk.uio.no/trygver/1979/sysreq/SysReq.pdf SysReq.pdf].</ref><ref name="FowlerPoEAA">{{cite book |last=Fowler |first=Martin |author-link=Martin Fowler (software engineer) |date=2003 |title=Patterns of Enterprise Application Architecture |publisher=Pearson Education, Inc. |isbn=0-321-12742-0}}</ref>{{rp|name=FowlerPoEAA |p=330 |q=''Model View Controller''...started as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s.}} He wanted a pattern that could be used to structure any program where users interact with a large, convoluted [[data set]]. His design initially had four parts: [[Model]], view, thing, and editor. After discussing it with the other Smalltalk [[Software development|developers]], he and the rest of the group settled on model, view, and controller instead.<ref name="page_trygver" />

In their final design, a model represents some part of the program purely and intuitively. A view is a visual representation of a model, retrieving data from the model to display to the user and passing requests back and forth between the user and the model. A controller is an organizational part of the user interface that lays out and coordinates multiple Views on the screen, and which receives user input and sends the appropriate messages to its underlying Views. This design also includes an Editor as a specialized kind of controller used to modify a particular view, and which is created through that view.<ref name="page_trygver" />

Smalltalk-80 supports a version of MVC that evolved from this one.<ref name="page_trygver" /> It provides abstract <code>view</code> and <code>controller</code> [[Class (computer programming)|classes]] as well as various concrete subclasses of each that represent different generic [[Software widget|widgets]]. In this scheme, a <code>View</code> represents some way of displaying information to the user, and a <code>controller</code> represents some way for the user to interact with a <code>view</code>. A <code>view</code> is also coupled to a model object, but the structure of that object is left up to the application [[programmer]]. The Smalltalk-80 environment also includes an "MVC Inspector", a development tool for viewing the structure of a given model, view, and controller side-by-side.<ref name="smalltalk_redbook">{{cite book |last=Goldberg |first=Adele |author-link=Adele Goldberg (computer scientist) |title=Smalltalk-80: The Interactive Programming Environment |date=1984 |publisher=Addison-Wesley |isbn=0-201-11372-4}}</ref>

In 1988, an article in ''[[The Journal of Object Technology]]'' (JOT) by two ex-PARC employees presented MVC as a general "[[programming paradigm]] and methodology" for Smalltalk-80 developers. However, their scheme differed from both Reenskaug et al.'s and that presented by the Smalltalk-80 reference books. They defined a view as covering any graphical concern, with a controller being a more abstract, generally invisible object that receives user input and interacts with one or many views and only one model.<ref name="art1">{{cite journal|first1= Glenn E.|last1= Krasner|first2= Stephen T.|last2= Pope|title= A cookbook for using the model–view controller user interface paradigm in Smalltalk-80|url= http://dl.acm.org/citation.cfm?id=50757.50759|publisher= SIGS Publications|date= Aug–Sep 1988|journal= [[The Journal of Object Technology]]|volume= 1|issue= 3|pages= 26–49}} Also published as "[https://web.archive.org/web/20100921030808/http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf A Description of the Model–View–Controller User Interface Paradigm in the Smalltalk-80 System]" (Report), ParcPlace Systems; Retrieved 2012-06-05.</ref>

The MVC pattern subsequently evolved,<ref name="Fowler">[http://martinfowler.com/eaaDev/uiArchs.html The evolution of MVC and other UI architectures] from Martin Fowler.</ref> giving rise to variants such as [[hierarchical model–view–controller]] (HMVC), [[model–view–adapter]] (MVA), [[model–view–presenter]] (MVP), [[model–view–viewmodel]] (MVVM), and others that adapted MVC to different contexts.

The use of the MVC pattern in [[web application]]s grew after the introduction of [[NeXT]]'s [[WebObjects]] in 1996, which was originally written in [[Objective-C]] (that borrowed heavily from Smalltalk) and helped enforce MVC principles. Later, the MVC pattern became popular with Java developers when WebObjects was ported to [[Java (programming language)|Java]]. Later frameworks for Java, such as [[Spring Framework|Spring]] (released in October 2002), continued the strong bond between Java and MVC.

In 2003, [[Martin Fowler (software engineer)|Martin Fowler]] published ''Patterns of Enterprise Application Architecture'', which presented MVC as a pattern where an "input controller" receives a request, sends the appropriate messages to a model object, takes a response from the model object, and passes the response to the appropriate view for display.{{r| name="FowlerPoEAA" |p=56 |q=A request comes in to an input controller...It then forwards the business logic to an appropriate model object. The model object talks to the data source...it [then] returns control to the input controller, which...decides which view is needed to display the response. It then passes control, together with the response data, to the view.}} This is close to the approach taken by the [[Ruby on Rails]] web application framework (August 2004), which has the client send requests to the server via an in-[[Web browser|browser]] view, these requests are handled by a controller on the server, and the controller communicates with the appropriate model objects.<ref>{{cite web |url=https://guides.rubyonrails.org/ |title=Ruby on Rails Guides |access-date=March 19, 2022}}</ref> The [[Django (web framework)|Django]] framework (July 2005, for [[Python (programming language)|Python]]) put forward a similar "model-template-view" (MTV) take on the pattern, in which a view retrieves data from models and passes it to templates for display.<ref>{{cite web |url=https://docs.djangoproject.com/en/4.0/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names |title=Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names? |access-date=March 19, 2022}}</ref> Both Rails and Django debuted with a strong emphasis on rapid deployment, which increased MVC's popularity outside the traditional enterprise environment in which it has long been popular.

==Components==

===Model===
{{See also|Data model}}
The central component of the pattern. It is the application's dynamic [[data structure]], independent of the user interface.<ref>Burbeck, Steve (1992) [https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html Applications Programming in Smalltalk-80:How to use Model–View–Controller (MVC)]</ref> It directly manages the data, logic and rules of the application. In Smalltalk-80, the design of a model type is left entirely to the programmer.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=8 |quote=The model can be any object without restriction.}}</ref> With WebObjects, Rails, and Django, a model type typically [[object–relational mapping|represents]] a table in the application's [[database]].<ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |date=May 2001 |title=WebObjects System Overview |url=https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf |location=Cupertino, CA |publisher=Apple Computer, Inc. |page=28 |quote=In WebObjects, a model establishes and maintains a correspondence between an enterprise object class and data stored in a relational database.}}</ref><ref>{{cite web |url=https://guides.rubyonrails.org/active_record_basics.html |title=Active Record Basics |author=<!--Not stated--> |date=<!--Not stated--> |website=Rails Guides |access-date=October 27, 2022 |quote=This will create a <code>Product</code> model, mapped to a products table at the database.}}</ref><ref>{{cite web |url=https://docs.djangoproject.com/en/4.1/topics/db/models/ |title=Models |author=<!--Not stated--> |date=<!--Not stated--> |website=Django Documentation |access-date=October 27, 2022 |quote=Generally, each model maps to a single database table.}}</ref> The model is essential for keeping the data organized and consistent. It ensures that the application's data behaves according to the defined rules and logic.

===View===
Any representation of information such as a [[chart]], diagram or table. Multiple views of the same information are possible, such as a bar chart for management and a tabular view for [[accountant]]s.

In Smalltalk-80, a view is just a visual representation of a model, and does not handle user input.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=8 |quote=The view is responsible for providing a visual representation of the object.}}</ref> With WebObjects, a view represents a complete user interface element such as a menu or button, and does receive input from the user.<ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |date=May 2001 |title=WebObjects System Overview |url=https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf |location=Cupertino, CA |publisher=Apple Computer, Inc. |page=28 |quote=View objects represent things visible on the user interface (windows, for example, or buttons).}}</ref> In both Smalltalk-80 and WebObjects, however, views are meant to be general-purpose and [[Composability|composable]].<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=8 |quote=[MVC] permits views to be used as parts for assembly into larger units; new kinds of views can be constructed using existing views as subviews.}}</ref><ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |date=May 2001 |title=WebObjects System Overview |url=https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf |location=Cupertino, CA |publisher=Apple Computer, Inc. |page=28 |quote=View objects tend to be very reusable and so provide consistency between applications.}}</ref>

With Rails and Django, the role of the view is played by [[HTML]] templates, so in their scheme a view specifies an in-browser user interface rather than representing a user interface widget directly.<ref>{{cite web |url=https://guides.rubyonrails.org/action_view_overview.html |title=Action View Overview|author=<!--Not stated--> |date=<!--Not stated--> |website=Rails Guides |access-date=October 27, 2022 |quote=Action View templates are written using embedded Ruby in tags mingled with HTML.}}</ref><ref>{{cite web |url=https://docs.djangoproject.com/en/4.1/topics/templates/ |title=Templates |author=<!--Not stated--> |date=<!--Not stated--> |website=Django Documentation |access-date=October 27, 2022 |quote= A template contains the static parts of the desired HTML output as well as some special syntax describing how dynamic content will be inserted.}}</ref> (Django opts to call this kind of object a "template" in light of this.<ref>{{cite web |url=https://docs.djangoproject.com/en/4.0/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names |title=Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names? |access-date=October 27, 2022}}</ref>) This approach puts relatively less emphasis on small, composable views; a typical Rails view has a [[Cardinality (data modeling)|one-to-one relationship]] with a controller action.<ref>{{cite web |url=https://guides.rubyonrails.org/action_view_overview.html |title=Action View Overview |author=<!--Not stated--> |date=<!--Not stated--> |website=Rails Guides |access-date=October 27, 2022 |quote=Typically, the views share their name with the associated controller action...}}</ref>

Smalltalk-80 views communicate with both a model and a controller,<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=9 |quote=...the view knows explicitly about the model and the controller.}}</ref> whereas with WebObjects, a view talks only to a controller, which then talks to a model.<ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |date=May 2001 |title=WebObjects System Overview |url=https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf |location=Cupertino, CA |publisher=Apple Computer, Inc. |page=28 |quote=Acting as a mediator between Model objects and View objects in an application is a Controller object.}}</ref> With Rails and Django, a view/template is used by a controller/view when preparing a response to the client.<ref>{{cite web |url=https://guides.rubyonrails.org/action_view_overview.html |title=Action View Overview |author=<!--Not stated--> |date=<!--Not stated--> |website=Rails Guides |access-date=October 27, 2022 |quote=In Rails, web requests are handled by action controller and action view. Typically, action controller is concerned with communicating with the database and performing CRUD actions where necessary. Action View is then responsible for compiling the response.}}</ref><ref name="djangoviewtemplfaq">{{cite web |url=https://docs.djangoproject.com/en/4.0/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names |title=Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names? |access-date=October 27, 2022 |quote=In Django, a 'view' describes which data is presented, but a view normally delegates to a template, which describes how the data is presented.}}</ref>

===Controller===
[[File:UML class diagram MVC controller.svg|thumb|UML class diagram of a example controller in MVC architecture]]
Accepts input and converts it to commands for the model or view.<ref>[http://www.codeproject.com/Articles/25057/Simple-Example-of-MVC-Model-View-Controller-Design Simple Example of MVC (Model–View–Controller) Architectural Pattern for Abstraction]</ref>

A Smalltalk-80 controller handles user input events, such as button presses or mouse movement.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=8 |quote=The controller is responsible for interfacing between the user and the model/view. It interprets keyboard characters along with mouse movements and clicking.}}</ref> At any given time, each controller has one associated view and model, although one model object may hear from many different controllers. Only one controller, the "active" controller, receives user input at any given time; a global [[window manager]] object is responsible for setting the current active controller. If user input prompts a change in a model, the controller will signal the model to change, but the model is then responsible for telling its views to update.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |page=11}}</ref>

In WebObjects, the views handle user input, and the controller mediates between the views and the models. There may be only one controller per application, or one controller per window. Much of the application-specific logic is found in the controller.<ref>{{cite book |author=<!--Staff writer(s); no by-line.--> |date=May 2001 |title=WebObjects System Overview |url=https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf |location=Cupertino, CA |publisher=Apple Computer, Inc. |page=28}}</ref>

In Rails, requests arriving at the on-server application from the client are sent to a "router", which maps the request to a specific method of a specific controller. Within that method, the controller interacts with the request data and any relevant model objects and prepares a response using a view. Conventionally, each view has an associated controller; for example, if the application had a <code>client</code> view, it would typically have an associated <code>Clients</code> controller as well. However, developers are free to make other kinds of controllers if they wish.<ref>{{cite web |url=https://guides.rubyonrails.org/action_view_overview.html |title=Action View Overview |author=<!--Not stated--> |date=<!--Not stated--> |website=Rails Guides |access-date=October 27, 2022 |quote=Typically, the views share their name with the associated controller action...}}</ref>

Django calls the object playing this role a "view" instead of a controller.<ref name="djangoviewtemplfaq" /> A Django view is a function that receives a web request and returns a web response. It may use templates to create the response.<ref>{{cite web |url=https://docs.djangoproject.com/en/4.1/topics/http/views/ |title=Writing views |author=<!--Not stated--> |date=<!--Not stated--> |website=Django Documentation |access-date=October 27, 2022}}</ref>

==Interactions==
In addition to dividing the application into a model, a view and a controller component, the MVC [[Software design pattern|design pattern]] defines the interactions between these three components :<ref name="posa">Buschmann, Frank (1996) ''Pattern-Oriented Software Architecture''.</ref>
* The model is responsible for managing the data of the application. It receives user input from the controller.
* The view renders presentation of the model in a particular format.
* The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.

As with other software patterns, MVC expresses the "core of the solution" to a problem while allowing it to be adapted for each system.<ref name="gof">Gamma, Erich et al. (1994) ''Design Patterns''</ref> Particular MVC designs can vary significantly from the traditional description here.<ref>Moore, Dana et al. (2007) ''Professional Rich Internet Applications: Ajax and Beyond'': "Since the origin of MVC, there have been many interpretations of the pattern. The concept has been adapted and applied in very different ways to a wide variety of systems and architectures."</ref>

== Motivation ==
As [[Alan Kay]] wrote in 2003, the original motivation behind the MVC was to allow creation of a graphical interface for any object.<ref name=":0">{{Cite web |title= is squeak really object oriented ? |url= http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/058824.html |author= Alan Kay |work= Squeak Foundation mailing list |date= 23 May 2003 |access-date= 26 October 2021 }}</ref> That was outlined in detail in Richard Pawson's book ''[[Naked objects|Naked Objects]]''.<ref name=":0" />

Trygve Reenskaug, originator of MVC at PARC, has written that "MVC was conceived as a general solution to the problem of users controlling a large and complex data set."<ref name="page_trygver" />

In their 1991 guide ''Inside Smalltalk'', [[Carleton University]] computer science professors Wilf LaLonde and John Pugh described the advantages of Smalltalk-80-style MVC as:
* independence of presentation and data, e.g. multiple views on one model simultaneously,
* composable presentation widgets, e.g. one view used as a subview of another,
* switchable input modes, by swapping one controller out for another during [[Software execution|runtime]], and
* independence of input and output processing, via the [[Separation of concerns|separate responsibilities]] of controllers and views.<ref>{{cite book |last1=LaLonde |first1=Wilf R. |last2=Pugh |first2=John R. |date=1991 |title=Inside Smalltalk |url=https://books.google.com/books?id=RRkiAQAAIAAJ |volume=2 |location=U.S.A. |publisher=Prentice-Hall Inc. |isbn=0-13-467309-3 |pages=8–9}}</ref>

==Use in web applications==
Although originally developed for [[Desktop computer|desktop computing]], MVC has been widely adopted as a design for [[World Wide Web]] applications in major [[programming language]]s. Several [[web framework]]s have been created that enforce the pattern. These [[software framework]]s vary in their interpretations, mainly in the way that the MVC responsibilities are divided between the [[client–server model|client and server]].<ref name="leff">{{cite conference|first1=Avraham|last1=Leff|first2=James T.|last2=Rayfield|title=Web-Application Development Using the Model/View/Controller Design Pattern|date=September 2001|conference=IEEE Enterprise Distributed Object Computing Conference|pages=118–127}}</ref> Early MVC frameworks took a [[thin client]] approach that placed almost the entire model, view and controller logic on the server. In this approach, the client sends [[hyperlink]] requests or [[form (web)|form]] submissions to the controller and then receives a complete and updated [[web page]] (or other document) from the view; the model exists entirely on the server.<ref name="leff"/> Later frameworks have allowed the MVC components to execute partly on the client, using [[Ajax (programming)|Ajax]] to synchronize data.

==See also==
{{cmn|colwidth=20em|
* [[Action–domain–responder]]
* [[Bistro Framework]]
* [[Entity–control–boundary|Entity–control–boundary pattern]]
* [[Hierarchical model–view–controller]]
* [[Model–view–adapter]]
* [[Model–view–presenter]]
* [[Model–view–viewmodel]]
* [[Multitier architecture]]
* [[Observer pattern]]
* [[Presentation–abstraction–control]]
* [[Separation of concerns]]
* [[Strategy pattern]]
}}

==References==
{{reflist}}

==Bibliography==
{{Wikibooks|Computer Science Design Patterns/Model–view–controller}}

{{Design patterns}}
{{Smalltalk programming language}}

{{DEFAULTSORT:Model-view-controller}}
[[Category:Architectural pattern (computer science)]]
[[Category:Software design patterns]]