Last updated at 2:35 am UTC on 11 February 2014
MVC stands for Model-View-Controller.
Model-View-Controller is the paradigm behind the traditional Smalltalk-80 user interface. (The Smalltalk-80 MVC user interface is the original GUI with overlapping windows, later imitated by the Macintosh and Windows.)
The Model-View-Controller pattern is one of the earliest and one of the most successful design patterns. It was developed by Trygve Reenskaug in 1979, years before the notion "design pattern" was coined. On his homepage, which is certainly worth a visit, you find the papers that he wrote in 1979 about the MVC pattern: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html (Trygve has recently been working with Squeak, see BabySRE.)
In Squeak, MVC is available as one of the user interface environments to work within, and is a direct descendent of the original Smalltalk-80 MVC. The other user interface environment is Morphic, which is somewhat newer, originally developed for the language Self, and then ported to Squeak. (You can tell if you're inside the MVC UI by looking for the unusual gray and white scrollbars with no arrow buttons... see the MVC Screenshot. The Morphic UI has a more standard scrollbar with arrow buttons.) To play with the MVC UI in Squeak, select "open..." from the World menu, and then "mvc project", and click on the new Unnamed window to enter the MVC project.
The MVC paradigm has been copied from Smalltalk-80 and used in other UI frameworks. The Java Swing UI and Struts, for example, are based on MVC. (See MVC Meets Swing.)
There is a paper describing MVC in some detail at http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html. Here is a brief excerpt from the paper:
In the MVC paradigm 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, each specialized for its task.
The formal separation of these three tasks is an important notion that is particularly suited to Smalltalk-80 where the basic behavior can be embodied in abstract objects: View, Controller, Project - various notes and Object.
- The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application.
- The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate.
- Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).