Editing Model–view–controller (section)

==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===
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>