Model View Controller

An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two. -- ConnellyBarnes?

The Controller does not oversee the operation of the Views and Models - it's not a GodClass. The controller mediates communication and unifies validation, using either direct calls or the ObserverPattern.

Model-View-Controller is the concept introduced by Smalltalk's inventors (TrygveReenskaug and others) of encapsulating some data together with its processing (the model) and isolate it from the manipulation (the controller) and presentation (the view) part that has to be done on a UserInterface. Smalltalk provides mechanisms to link models, views and controllers in some standard way in order for a model to communicate state changes to every attached view (there can be several, as you can see). Model state changes happen either because a controller issued some command or for some internal reason.

(Also see arguments against MVC: MvcIsNotObjectOriented.)

Note that the term Controller has adopted two radically different meanings - see WhatsaControllerAnyway. Also see MartinFowler's PatternsOfEnterpriseApplications?, who bemoans this greatly.

A triad of three modules linked by the ObserverPattern, all residing within a RepresentationLayer. The View drives a presentation within a GuiLayer, and elements within the View observe the Model. Elements within the Controller observe the View and Model, and elements within the Model observe the Controller. The Model fronts data objects within the LogicLayer.

This pattern decouples changes to how data are manipulated from how they are displayed or stored, while unifying the code in each component.

Alternative versions of this pattern appear in many architectures, and with various layer affiliations. Simplifications include Observing an entire component instead of elements within it, and using direct method invocations instead of Observation messages. Complications include substituting any element of the three components with another one.

I've started writing a history of MVC at ModelViewControllerHistory. -- MitchellModel

On ModelModelViewController I've highlighted that since the early days of Smalltalk MVC there have usually been two models involved. -- RandyStafford
Derivations & extensions to MVC

When a system obeys the principle DoTheMostComplexThingThatCouldPossiblyWork, marketects often respond by clumping its rambling notions together into 3 groups. The sub-SpaghettiCode group nearest the User becomes the "view", that nearest the database becomes the "model", and the stuff in between becomes the "controller".

Marketects then refer to their project's architecture as "MVC", borrowing that acronym's impressive lineage.

Sounds like SunMicrosystems's JavaLanguage PetStore

Is MVC a pattern? Several patterns? I propose an MVC pattern contest (either here or for PLoP). Ideas on how to proceed? This could be fun. -- JimCoplien
How does the more recent DocumentView architecture (presented in some windowing platforms) differ or resemble the older MVC? -- SkipSailors

They are similar in a way such that: -- ChaoKuoLin
MVC means many things to many people. That's why there will be many patterns with at least a connection to MVC. One of the last things we did in MondaySchool was to have a go at browser patterns (st-80 style browsers). I think they would count as MVC patterns too. Anyway, with that much latitude allowed, here is the list... On the other hand, AdeleGoldberg maintains that MVC is the solution to one specific problem and therefore just one pattern (though I doubt she would use the term.) She would say:
Not all people can or prefer to operate a computer in the same way.
Therefore, separate the controls of the computer from the views it presents so that appropriate controls can be selected by the user. A handicapped individual would be an example of a user needing a different kind of control.

I don't know of specific examples where this MVC capability has been exploited. Do you? -- WardCunningham

Perhaps web pages are an example of this - with the 'view' being css, 'model' being html, 'control' being, in part, the browser. I agree on this. I think javascript could be seen as the controller-part of the web-page. This becomes very apparent with Microsoft's lesser-known extension called behaviours. Behaviours are basically a declarative way of linking javascript code to styles (the view). Does anybody have any links on this perspective?

I'm not sure if it would be applicable, but Amiga programs used to widely support an AREXX "port" which allowed programs to be controlled through the REXX scripting language, basically by another process. Thus the user interface presented one view, and events therefrom constitute one "controller" while events from the AREXX port would seem to be a different "controller" (and return values from control events would presumably represent another view as well).

In this way, I'm a little unclear about why MVC separates V and C. If we think of VC (taken together) as "interface" then the whole MVC approach seems to simplify to ModelDelegate or client/server (or more formally, client - protocol - server). Does abstracting the controller somehow facilitate inter-object interactions? Does it make sense that some controls don't have a corresponding view, or is it that some controls may have to affect several views some of which don't offer any user interaction (and thus don't implement the control aspect of an "interface")?

What about SqueakSmalltalk's alleged handwriting recognition? I have not actually used it, but... -- BillTrost

Real-time audio apps do this. (Ardour for example). The controls are not the primary view, the audio ouput is, and we do not control the app with audio, but we may control it with two separated input controllers, a gui and perhaps a hardware interface over midi. Also, in well designed ones, the controllers are never allowed to jam the output, so they must be properly separated with some kind of queue to the model. So we wind up with an engine (model) that receives input from more than one control interface, but outputs a 'view' that is never tied in with controls. The view is notified whenever a model state changes. In the case of a gui, that too needs to get updated as a secondary 'view' but the hardware controllers do not. -- Iain Duncan

I can think of one instance I've seen. Back around 1992 EricSmith was asked by one of our clients to build a VT-100 interface to some Smalltalk (ObjectWorks 4.0) code. He did it by defining a VT-100 GraphicsTool? and a set of special-purpose Controllers for VT-100s (ListController?, ParagraphEditor?, etc.) that would translate keystroke combinations into the equivalent of mouse-moves. In this way his browsers would work the same on the workstation AND on the VT-100. -- KyleBrown
Like the original MVC article's title - "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80" (Glenn Krasner and Stephen Pope, JournalOfObjectOrientedProgramming, August/September 1988, http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf) - says, it's a paradigm. It's a conceptual framework for designing and implementing graphical user interfaces. A class library, such as Smalltalk-80's, would typically implement MVC based on abstract classes and default method definitions for models, views, and controllers - a Framework! -- MitchellModel

"A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80" is not the title of the original MVC article. A publication from 1979 by Trygve Reenskaug shows that the idea of MVC is much older: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf. -- TimoStamm?

A link to a decent explanation of MVC would be welcomed here. After spending a few hours searching today, I come home empty handed...Let me know if you have something please.

I found http://ootips.org/mvc-pattern.html to be useful. -- JohnClonts

Ward's collection of HotDraw CRC cards (http://c2.com/doc/crc/draw.html) helped me wrap my mind a little further around the concept.
I think that Model-View-Controller is good as far as it goes, but that some expansion of the concepts are needed. The development of JavaSwing provides some clues, I think.

I'm offering ModelPipeViewController for consideration, and would appreciate some feedback.

-- BruceAtherton
Apple's tutorial for Rhapsody - Discovering OpenStep - provides detailed examples of the MVC model, and a description of it. The documentation is in PDF, and you can find it at http://developer.apple.com/techpubs/rhapsody/DeveloperTutorial/index.html.

Chapter 2: A Simple Application provides a description, and Chapter 4: A Multi-Document Application probably provides the best example of the benefits. -- RonaldHayden
ModelViewPresenter tries to solve some of the drawbacks of mvc. What do the experts say? -- ThomasMahler
Here's an HTML version of SteveBurbeck's MVC paper: 
	http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
-- IanChai
WebMacro implements a ServletDesign based on Model/View/Controller. The argument is that, because the web works by returning HTML views to clients, an MVC design is inherent in server-side web programming. Java servlets, unlike CGI, make it more of a reality because they persist between connections and are most likely to have a middle-tier model underneath them. WebMacro is a free servlet framework that implements this ServletDesign. -- JustinWells

By the way, what is MVC2 in the servlet context? Why MVC1 was not enough and how does it differ from the original MVC? -- GuillermoSchwarz
I had an interesting chat with TrygveReenskaug this week. He notes that the original MVC had four objects: not only the model, view, and controller, but the user as well. He regrets that the fourth object has become lost in the popularization of the idiom.

He notes that MVC was an outgrowth of the original direct-manipulation metaphor popularized in early OO practice (see BrendaLaurel's ComputersAsTheatre), where you want the objects on the screen to be the objects in the program. MVC actually works against that metaphor but evolved as a necessary evil. Why? Because the user object maintains multiple simultaneous views of the model at once; the factoring into user, model, view, and controller allows one to support that. So while the speculation is that Adele would approach MVC from the input side, Trygve approaches it from the output side.

...which discussion of direct manipulation segues nicely into: MorphicInterface. In SqueakSmalltalk this is (apparently) replacing the MVC framework (not paradigm!). As someone else comments on the MorphicInterface page, there is very little information around on it. Despite having read Mark Guzdial's book on Squeak and the original papers on Morphic in the SelfLanguage I am none the wiser if there is really anything useful to be learned here (is it really an alternative way to structure programs than MVC?). Help me Obi wan, you're my only hope...
I've been trying to apply some of the ideas behind XP and the refactoring thing in VB, but am at a bit of a loss with MVC. Can anyone provide some simple examples?

See ModelViewControllerInVbClassicActiveServerPages.
The comment by TrygveReenskaug quoted above fits nicely with the way I like to think about MVC: I wouldn't push that too far, but it sometimes help me sort out design issues.

-- Don Dwiggins
One could make the case that MVC is more general than a user interface pattern. The user might be another piece of software (class). It would therefore include FacadePattern, VisitorPattern et al. -- TomRossen
Has anyone had much success with ModelViewController and the PalmOs? -- ScottElliott
MVC is exactly the same as BASIC. Let me explain! In BASIC you had INPUT, PRINT and LET and most of the code was just assembling them together, but your code written this way could not be assembled together. - This is completely incorrect. MVC is quite the contrary! If we apply that logic to any language able to accept input, process it, and generate output (that is, ANY computer language), any computer language would be the same as MVC. A computer language is used to implement the MVC pattern, but that doesn't make it a pattern language. Is like saying that brick and mortar is a house: in fact, a house is a pattern that can be built with brick and mortar, but that doesn't mean that a house is brick and mortar... it is the way brick and mortar are assembled what builds a house. -- LuisColorado

Then somebody realized that code should be organized the same way: Input, Output and internal processing. I/O was called the View/Controller and the internal processing was called the Model. Incorrect: in fact, the Model, the View, and the Controller are objects able to receive input and to provide output to the other components. -- LuisColorado

That is why Servlets are not MVC, nor Struts is MVC, nor J2EE is MVC. How do you know there are not? Because in MVC when you change the model, you don't need to change the view, since it is updated automagically. MVC is about direct manipulation of objects, they know how to display themselves, and because of that, the smaller objects must know how to display themselves. Big objects are made of smaller object that know how to display themselves, so big objects magically know how to display themselves. This is partially correct. I don't know of any language or technology that per se enforces MVC, and that includes J2EE, Servlets, etc. Another correction: in MVC, the Model objects don't know how to display themselves, neither have object that know how to do so. You are referring to the View objects. -- LuisColorado

The essential ingredient in MVC is the Observer pattern. Take that out and all you have left is IPO (Input-Process-Output). The Observer is what maintains encapsulation and keeps MVC strongly object-oriented. Without the Observer, you need setters and "this object here fiddling inside that object there" - decidedly non-OO.

-- MarcThibault

ModelViewController is one of the few design patterns to have been turned into a song: http://home.in.tum.de/pittenau/ModelViewController.mp3 (lyrics at http://www.oreillynet.com/pub/wlg/3533). That fourofoured for me. Alt location: http://vst.ensm-douai.fr/noury/20
Historically MVC patterns could have been promote as to allow magical switch of views around the same model or models around same view. Also many implementation library/tools had a design to facilitate composite of different MVC.

In fact for the MVC pattern the idea of model and view switching requires that the substitute view or model have the exact same interface with the controller than the original view or model otherwise the magical switch is broken. Change just one thing as a little different view dynamic behavior or one missing model method and the magical switch is broken.

Also in the MVC pattern there's absolutely no design to have composite MVC.

From this point of view you can design view as jsp with JavaBean views, Action as controller and models as JavaBean models to have a MVC pattern. That's enough to support the weak and too simple MVC pattern. -- BernardDevaux?
I've occasionally found MVC-ish patterns cropping up in my code more or less spontaneously; most recently in a small computer game. The model knows something's stats and location, the view knows how to draw on the screen, and the controller is particularly flexible, being the interface between a game object and the user... or the AI... or a network connection... or a limited-purpose AI like an autopilot...

Neat stuff.

-- SimonHeath
Computer Graphics Principles and Practice by Foley, van Dam, Feiner, Hughes (ISBN 020184840-6 ) presents an interesting description of the ModelViewController concept on pages 17 to 22. -- ChrisEineke
Links:
See: WhatsaControllerAnyway, DesignPrinciplesBehindSmalltalk, ModelModelViewController, ApplicationController, ModelViewControllerAsAnAggregateDesignPattern, MvcIsNotObjectOriented, MvcIsNotImplementable, ModelTargeterSurface, MvcVersusEventDriven, MongrelEeRuby

CategoryPattern CategoryUserInterface
EditText of this page (last edited September 13, 2009)
FindPage by searching (or browse LikePages or take a VisualTour)