Model View Controller History

See also ModelViewController, ModelModelViewController, and WhatsaControllerAnyway.

For such an influential idea the history of MVC architecture is shrouded in obscurity. Although I didn't contribute anything to MVC (other than talking about it in an OOPSLA-88 tutorial), I've been using, studying, teaching, and discussing MVC pretty much since it was invented, and I happen to have encountered several of its important evolutionary steps shortly after their appearance. I've often thought of writing a paper on the history of MVC, but haven't done that yet. There's enough Wiki discussion of MVC and uncertainty about its concepts and history that I finally [1/16/01] feel compelled to start capturing here what might go into such a paper. For now, these are just notes; I plan on elaborating them into something more coherent and useful over the next few weeks.

MitchellModel

MVC in Smalltalk

MVC was invented at Xerox Parc in the 70's, apparently by TrygveReenskaug. I believe its first public appearance was in Smalltalk-80. For a long time there was virtually no public information about MVC, even in Smalltalk-80 documentation. The first significant paper published on MVC was "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80", by Glenn Krasner and Stephen Pope, published in the August/September 1988 issue of the JournalOfObjectOrientedProgramming (JOOP).

I(?) worked with Glenn at ParcPlace. He, along with others who made the move from PARC to ParcPlace, credited TrygveReenskaug with MVC. --DaveSmith

MVC is the seminal insight of the whole field of graphical user interfaces. I believe the MVC work was the first to describe and implement software constructs in terms of their responsibilities. I also believe that MVC was the first significant use of protocols to define components instead of using concrete implementations -- each controller class had a certain set of messages it had to respond to, as did each view class, but otherwise there were no constraints on what they did and how they did it.

The dependency (addDependent:, removeDependent:, etc.) and change broadcast mechanisms (self changed and variations) made their first appearance in support of MVC (and in fact were rarely used outside of MVC). View classes were expected to register themselves as dependents of their models and respond to change messages, either by entirely redisplaying the model or perhaps by doing a more intelligent selective redisplay.

In the original formulation each view displayed a representation of all or part of one domain object, which could be a composite (and which typically had Model as a superclass, in order to obtain the requisite change notification capabilities). Although the intent was to support graphical interfaces for applications developed in Smalltalk, the tools of the Smalltalk environment -- browsers, in particular -- were also implemented using the MVC paradigm. Browsers were a little weird because a model's browser was a Browser object that in essence stood in for the image's classes, methods, class categories, and method protocols presented in the various browser panes. (Multi-pane browsers were present at least as early as Smalltalk-76, and I think even Smalltalk-72, though they weren't implemented using MVC then. The multi-pane browser paradigm was itself a powerful contribution, and over the years I have often found it convenient and easy to use it as a quick-and-dirty interface prototype for a wide variety of conceptual domains.)

[Need to add description of the Digitalk MVC architecture.]

Reflecting on the Smalltalk-80's experience with browsers and other MVC interfaces, developers at ParcPlace Systems (formed by members of PARC's Learning Research Group involved in the original development of Smalltalk, led by Adele Goldberg) redesigned the system tools for their ObjectWorks generation of Smalltalk products [around 1987 -- find actual date]. The realized that tool and application developers found themselves writing large numbers of text and list view classes, whereas the implementations differed not so much in how they displayed text and lists but rather in the specific details of common themes such as:

They developed pluggable views -- generic text and list views whose details were specified in many-argument methods used to create them. Pluggable views greatly reduced the number of individual view and controller classes needed in the system and in typical applications, because so many interfaces were composed largely or entirely of text and list panes.

In replacing ObjectWorks with VisualWorks (circa 1991 -- need exact date) ParcPlace once again redesigned the system tools and underlying MVC classes. Pluggable views disappeared. In their place were a set of small-grained GUI components familiar to users of contemporary toolkits: checkbox, button, text, field, list, combo box, etc. Each component was implemented as a tiny MVC interface, with its own view and controller classes. In a radical break from MVC tradition, the models of these components were implemented as small variable-like "value models" each holding the value displayed by a component. ValueModel subclasses included the basic ValueHolder? along with variations such as AspectAdaptor (which instead of a value held an object and the get and send selectors to send to that object to get or set the value) and BufferedValueHolder? (which would wrap something like an AspectAdaptor and hold a temporary value for editing that would get stored through the wrapped object only when a trigger was tripped, for use in coordinating updates through multiple components when the user presses something like an OK or Save button). The text and list classes were a lot simpler and easier to use than the pluggable ones found in ObjectWorks, while the idea of using flexible generic components to construct interfaces was extended to cover the other kinds of components that had become standard in GUI toolkits.

In VisualWorks the MVC framework is much less apparent to the programmer, who can easily construct interfaces using the system's GUI building tools without thinking about MVC at all. Even someone proficient in VisualWorks GUI library can take advantage of its more sophisticated component and model classes without thinking much about MVC. Moreover, since the component models are not domain objects, it isn't necessary -- though it is still possible and occasionally useful -- to manage dependencies on domain objects or include change broadcasts in domain methods. The GUI architecture pretty much assumes that all changes are made through the component models, either by user action or by interface code that changes those models directly, which means that the interface implementation (embodied in a subclass of the oddly named ApplicationModel) can monitor the state of the component models instead of the underlying domain objects. A classic MVC dependency/change mechanism is used for this, but through a new set of messages that sound higher level and don't reflect the underlying MVC design, such as onChange:send:to: sent to a component model. Consequently, programmers first encountering MVC in the VisualWorks environment often wonder what the all the fuss is about, if they even notice the MVC at all.

MVC Variations

Objective-C

The GUI library Stepstone provided with its ObjectiveCee development environment [at least as early as 1987 -- need exact date] modified MVC by combining each view-controller pair in a single class....

ObjectOrientedProgrammingAnEvolutionaryApproach by BradCox makes extensive use of MVC

X Widget Sets

...

Java

...

My understanding is that TrygveReenskaug developed MVC collaboratively with PARC in 78/79. You might want to include some text on the SeeheimModel? or PAC (PresentationAbstractionControl). While slightly after MVC (I think 1983) they seem important

Pluggable views were part of Smalltalk-80 R2.0, which was in 1983 or 1984, long before ParcPlace was formed. So, pluggable views predate ObjectWorks by several years. -RalphJohnson

(embodied in a subclass of the oddly named ApplicationModel?)

Actually, that is not such an odd name at all - it is merely a recognition, via reification, of an abstraction that had been present in MVC applications since the beginning - and there is a quite a bit of documentation around its reason for existence. See ModelModelViewController. --RandyStafford

EditText of this page (last edited December 26, 2014) or FindPage with title or text search