I spent a very happy and inspiring year as a visiting scientist with the Learning Research Gorup (LRG) at Xerox PARC from the summer og 1978 to the summer of 1979. This group was dedicated to Alan Kay's vision of the Dynabook; a portable computer that should contain all data of interest to its owner/user. Very importantly, these data included the programs the owner used to manipulate them. The owner/user should be able to understand and write the programs, thus gaining ascendancy over the computer.
The MVC notes should be read on this background. The user was the czar; everything done at LRG was done to support him. An earlier paper adds some background for MVC:
A note on DynaBook requirements
22 March 1979 (Partial scan, 11 pp
I have sometimes been given more credit than is my due, so I should stress that I am not one of the original inventors of Smalltalk. I am only one of the very early and very enthusiastic users and contributors to this revolutionary innovation. I made the first implementation and wrote the original MVC note at Xerox PARC in 1978. The note defines four terms; Model, View, Controller and Editor . The Editor is an ephemeral component that the View creates on demand as an interface between the View and the input devices such as mouse and keyboard.
Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library after I had left Xerox PARC; I was in not involved in this work. Jim Althoff uses the term Controller somewhat differently from me. An important aspect of the original MVC was that its Controller was responsible for creating and coordinating its subordinate views. Also, in my later MVC implementations, a view accepts and handles user input relevant to itself. The Controller accepts and handles input relevant to the Controller/View assembly as a whole, now called the Tool.
The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints. The figure below illustrates the idea.
MVC was conceived as a general solution to the problem of users controlling a large and complex data set. The hardest part was to hit upon good names for the different architectural components. Model-View-Editor was the first set:
12 May 1979 (11 pp)
PDF (11 pp, 312,594 bytes)
After long discussions, particularly with Adele Goldberg, we ended with the terms Model-View-Controller:
10 December 1979 (2 pp)
(.PDF (2 pp, 9,696 bytes)
The two papers have been copied together here:
(PDF, 396 567 bytes)
The Controller was here what I now call a Tool. The Smalltalk-80 Controller is here a fourth element called Editor. This was an ephemeral component that the View creates on demand as an interface between the View and the input devices such as mouse and keyboard.
The MVC problem has more facets than I realized in 1979. I started working on a pattern language to disentangle the different aspects, that last draft was dated August 20, 2003. The plan was that it should be improved by a group of authors, not just the current single one. Unfortunately, the projct died at his point.
MVC Pattern Language
.PDF (1 029 554 bytes)
Also see The Model-View-Controller (MVC ). Its Past and Present below:
|The Model-View-Controller (MVC ).
Its Past and Present
JavaZONE, Oslo, 2003.
JAOO, Århus, 2003
Handout with draft pattern language .PDF
|mvc, uml||MVC was conceived in 1978 as the design solution to a particular problem. The top level goal was to support the user's mental model of the relevant information space and to enable the user to inspect and edit this information. The first part of the talk describes the original problem and discusses the chosen solution. The second part elaborates the original ideas and extends the scope to include current day challenges to the original goal. It is all summarized in a condensed MVC pattern language.|
an Example from a planningsystem.
Xerox PARC technical note May 1979.
|is21c, mvc, roles||The original MVC report. The yards of the Aker Group in Norway have been using network techniques and ad hoc methods for planning and control for many years. The systems used have not been satisfactory, and a new modelling tool was devised for the yards. The basic building block of this tool is considerably more powerful than the activity of the traditional networks. It is called a Component, and carries both its own data and the algorithms needed to manipulate them. Each Component represents an identifiable portion of the real world in the yard. The planning process consists of the Components sending information to each other (messages), and acting upon information received.|
|MODELS - VIEWS - CONTROLLERS
Xerox PARC technical note December 1979
|is21c, mvc, roles||Defines the MVC terms|
|PROKON/PLAN-A MODELLING TOOL FOR PROJECT PLANNING
Paper, IFIP Congress, Toronto, Canada, 1977
First published in the 1977 IFIP Proceedings.
Scanned by the author July 2003.
|is21c, roles, uml, mvc||The yards of the Aker Group in Norway have been using network techniques and ad hoc methods for planning and control for many years. The systems used have not been satisfactory, and a new moelling tool was devised for the yards. The basic building block of this tool is considerably more powerful than the activity of the traditional networks. It is called a Component, and carries both its own data and the algorithms needed to manipulate them. Each Component represents an identifiable portion of the real world in the yard. The planning process consists of the Components sending information to each other (messages), and acting upon information received. An experimental system for the planning and control of the Design Sector of A/S Bergens Mekaniske Verksteder has been developed.|
|ADMINISTRATIVE CONTROL IN THE
Paper, ICCAS conference, Tokyo, 1973.
Scanned by the author July 2003
|is21c, components, architecture, mvc,||The organisation of a yard may be strongly influenced by the information system it takes into use. The converse should also be true: Systems development should be subordinated the desired evolution of the organisation. The principle of Communicating Data Processes is introduced as a tool for building information systems that are easily moulded for fitting an existing organisation and for adaption to its continuous development. A description of the principle is given, as well as an outline of a new system designed for testing it out in practical shipbuilding.|