See also Model View Controller, Model Model View Controller, and Whatsa Controller Anyway.
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.
MVC in Smalltalk
MVC was invented at Xerox Parc in the 70's, apparently by Trygve Reenskaug. 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 Journal Of Object Oriented Programming (JOOP).
I(?) worked with Glenn at Parc Place. He, along with others who made the move from PARC to Parc Place, credited Trygve Reenskaug with MVC. --Dave Smith
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 Parc Place 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 Object Works 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:
what commands appeared on the middle-button ("yellow" in Smalltalk-80 and earlier, "" in Visual Works) menu and the methods implementing them
what message to send to the model to get the data they displayed or store a new value (anticipating the Aspect Adapters of Visual Works)
...
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 Object Works with Visual Works (circa 1991 -- need exact date) Parc Place 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. Value Model subclasses included the basic Value Holder along with variations such as Aspect Adaptor (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 Buffered Value Holder (which would wrap something like an Aspect Adaptor 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 Object Works, 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 Visual Works 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 Visual Works 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 Application Model) 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 Visual Works 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 Objective Cee development environment [at least as early as 1987 -- need exact date] modified MVC by combining each view-controller pair in a single class....
Object Oriented Programming An Evolutionary Approach by Brad Cox makes extensive use of MVC
X Widget Sets
...
Java
...
My understanding is that Trygve Reenskaug developed MVC collaboratively with PARC in 78/79. You might want to include some text on the Seeheim Model or PAC (Presentation Abstraction Control). 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 Parc Place was formed. So, pluggable views predate Object Works by several years. -Ralph Johnson
(embodied in a subclass of the oddly named Application Model?)
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 Model Model View Controller. --Randy Stafford
See original on c2.com 