Pardon the long length of this. I've tried to incorporate as much research as I can. This is on the edge of where a wiki page ends and a PDF article begins.
What's a Controller, Anyway?
An accountant who gets promoted?
Computer scientists in general have an annoying tendency to overload terms. That is to say, they tend to assign more than one meaning (sometimes contradictory) to the same word. A prime example of this, and an interesting study in how meanings change when conveyed from person to person (as in the telephone game), is how the meaning of the term "Controller" changed from the early days of Smalltalk into its now mostly-accepted meaning.
One of the central ideas of the Smalltalk-80 system was the Model View Controller (MVC) User Interface Paradigm. Within that paradigm, the term "controller" had a well-defined, limited meaning. One of the first discussions of MVC, "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80" acm 
, by Glenn Krasner and Stephen Pope, was published in the August/September 1988 Journal Of Object Oriented Programming. It defined MVC as follows:
web.archive.org
<-- controller!
"Model View Controller (MVC) programming is the application of this three-way factoring whereby objects of different classes take over the operations related to the application domain (the model), the display of the application's state (the view), and the user interaction with the model and the view (the controller)."
Later, the article more closely defines these terms:
"Models -- The model of an application is the domain-specific software simulation or implementation of the application's central structure."
"Views -- In this metaphor, views deal with everything graphical: they request data from their model and display the data."
"Controllers -- Controllers contain the interface between their associated models and views and the input devices (e.g., keyboard, pointing device, time)."
In this interpretation, controllers are simple, well-constrained classes that handle processing of the event loop for a particular view. To Smalltalk-80 (and Visual Works) programmers, a "Controller" is something that subclasses "Controller" and nothing else.
However, an interesting reinterpretation of MVC came about in the early 1990s. I believe that a major architect of this reinterpretation was Ivar Jacobson, who wrote about a similar but not identical architecture in his book, "Object-Oriented Software Engineering: A Use Case Driven Approach" in 1992.
Jacobson was not much concerned with low-level programming constructs in his book. Instead, he was presenting a method of analysis and design to allow developers to build large systems. As such, he "re-adapted" some terms or possibly independently reinvented them.
A major focus of Jacobson's book was in developing several "Models" of a large system based around Use Cases. After defining a Requirements model, his method moves on to define an Analysis Model. In his own words: "This model aims to structure the system independently of the actual implementation environment".
Later, he describes the overall structure of the Analysis Model. In his words, "In the information space of this model, our aim is to capture information, behavior and presentation. The Analysis Model is built by specifying objects in this information space." Finally, he states "Many object-oriented analysis methods choose to have only one object type, which can be placed anywhere within this space. We have chosen to use three object types. The object types used in the Analysis Model are entity objects, interface objects and control objects".
In his definitions of these objects, we see that although this definition bears a superficial resemblance to MVC, it has a very different purpose. For instance, when he begins defining his terms, he states "All functionality specified in the use case descriptions that is directly dependent on the system environment is placed in the interface objects. Interface objects can, in other words, describe bi-directional communication between the system and its users".
Ivar goes on to describe his entity objects as being close to what MVC has described as one type of Model objects - that is to say those objects found in the analysis of the problem domain. This leaves the question of his control objects - what are they? Jacobson himself states: "...in more complex use cases, there often remains behavior that is not naturally placed in either of these two object types [meaning entity and interface objects]. Such behavior is placed in control objects. The control objects typically act as glue which unites other objects so that they form one use case".
So, here we see a completely different meaning for "control" or "controller" from what was defined for the "controller" in Smalltalk-80. What happened is that Jacobson's definition (which comes closer to the traditional English meaning of the word "control") has become adopted more and more frequently, to the detriment of the other meaning.
Now, Ivar was not the only person to redefine the term, or provide a similar meaning. As far back as 1987, a paper by Joelle Coutaz referenced in Pattern Oriented Software Architecture One proposed a system called Presentation Abstraction Control (PAC), which maps (roughly) to the notions of View/Controller, Model, and Mediator. This was written in pattern form in POSA in 1995.
Also, in 1992, Greg Hendley and Eric Smith wrote a series of articles in the Smalltalk Report describing what they referred to as the "Interface-Control-Model (ICM)" architecture. This was again, somewhat similar to Jacobson's concept and nearly identical to the PAC architecture.
So, why do we care about this fiddling over meaning? The answer is that in Java BOTH meanings are bandied about. For instance, Java Swing is discussed as being derived from a pure MVC architecture. The major difference being that in Swing, the View and Controller (using terms adopted from Smalltalk-80) are folded together into a single component. In the words of the Getting Started with Swing document on Sun's web site "traditional MVC architecture makes it very hard to create a generic controller that doesn't know at design time what kind of view will eventually be used to display it." This sentence shows they understood the Smalltalk-80 meanings of a view and a controller and chose to NOT incorporate them into their design.
However, MVC is often used as a synonym for something closer to PAC or ICM. I myself have been guilty of this, as I was in my recent (June 1999) Java Report article called "Using Server-Side Java Successfully".
So, who out there knows who was originally responsible for the redefinition? Where have you seen MVC used as a synonym for PAC? Do you think Jacobson was mostly responsible, or was there another popular redefinition that I've missed?
-- Kyle Brown
The two meanings aren't as different as they seem. In both cases, the Controller is the element responsible for processing change. Whether the major work here is in capturing user input or routing the different layers depends on the environment.
In Web Apps, a Controller has to authenticate, parse the request, validate it, and deduce the appropriate procedures (or methods to run). This is all a consequence of Web Apps being remote (so we need validation), stateless, and done over a narrow channel (URL + request). So, the Controller functions mainly as glue.
In a local rich client GUI, on the other hand, none of this is necessary - it's stateful, so there's no need to load a context. It's local, so we don't need to worry about validation. It's in process, so we don't need to parse requests and deduce procedures - we can just hook them up in source (via callbacks or delegates or whatever). On the other hand, we do need to spend a lot of time capturing and deducing user input from keys and the mouse. So, it makes sense to call this element the controller. (In Web App's, this is all done for us, and serialized to a narrow channel - the URL and request.)
In both cases, the Controller is the element for processing and routing change. The difference is only whether the bulk of that work lies in capturing the input or setting up an app flow based on it.
Comments? Do you agree?
So, who out there knows who was originally responsible for the redefinition?
I take it that part of the responsibility lies with the Openstep App Kit. It's claimed to use MVC, but actually the "C" is mediating between "M" and "V". -- Michael Schuerig
Good catch on this one. Here is a link that proves Apple/NEXT's reinterpretation: developer.apple.com
''(This URL no longer works. I guess this is the same document:
developer.apple.com
-- Peter Lindberg)''
Apple also has this guide, which has a section on Model View Controller in the context of the Cocoa Framework:
developer.apple.com
Now - here's another question. Does anyone know if Mac App similarly defined things this way? I seem to remember that Mac App originated the Document-View architecture, but I don't remember anything about controllers. -- Kyle Brown
I just had a phone conversation with Steve Burbeck, who assures me that there was nothing like either a Mediator or Controller in Mac App. So that closes down that avenue. -- Kyle Brown
What happened in Mac App, at least in the early versions, was that the Controller was part of the View. While there was no explicit controller (Mr Burbeck is correct here), after all something has to deal with what is happening with the mouse and the keyboard. This turned out to be the View. So for Mac App the Document is the Model, and View takes the role of the View and the Controller. -- Richard Collins
Interesting discussion - I've been trying to digest two recent articles in Java World magazine by Allen Holub. In the first http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html www.javaworld.com he completely lambasts MVC, then in the second http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html www.javaworld.com, he promotes Presentation Abstraction Control (PAC). I've never written a line of Smalltalk code, but I do have a couple of co-workers who have and they got quite up-in-arms about these articles. This PAC pattern is what I have been thinking is MVC all along, so I was wondering Whatsa Controller Anyway too.
In MVC, the Controller is a strategy that the view uses to handle user input. In the original MVC, it polls for user actions, but it can also be event-driven. The purpose is to handle fairly low-level events. In PAC, the Control is a mediator. Mediator is a fine pattern, but it has a different purpose and solves a different problem. It is used to implement use cases, i.e., the high-level control, while Controllers handle the low-level control. Both are useful, as shown by the fact that Visual Works has introduced Application Model as a mediator. In Visual Works, View and Controller make up the P in PAC and Application Model makes up the C. The A is just the regular model, which Visual Works developers sometimes call the domain model. -- Ralph Johnson
who was originally responsible for the redefinition?
It's probably impossible to identify a single person who was originally responsible, but I just came across an early culprit who has heretofore escaped mention on this page: Jim Rumbaugh. In a September 1994 Journal Of Object Oriented Programming article he urges readers to "use the model-view-controller framework" and then, in the very next paragraph, he proceeds to write: "the state diagram of a controller defines the allowable sequences of interactions inherent in a use case ... Start by assuming one controller per use case...". So, clearly, by 1994 prominent methodologists were mis-using the paradigm's name by substituting the Jacobsonian connotation (i.e., use-case sequencer) for the Smalltalk connotation (input device interface). -- Randy Stafford (2002/04/04)
'It sounds like you are saying that Visual Works has four levels: interface widgets, a dialog coordinator, a use case implementor, and a persistent model. Is that right? These are the four levels that I use in my code but I've never seen any tool support for them. I'm confused though, you said that the use case implementing part is a GoF Mediator, but I use Mediator to do the dialog coordination and other patterns to implement the parts of the use cases that the computer is responsible for. Maybe we aren't talking about the same thing after all. -- Phil Goodwin
Not really. Visual Works has three levels.
Views and Controllers (these together make up the UI widgets, or the P in PAC) Application Models (The C in PAC; what you call a dialog coordinator) Domain models (usually NOT separated into use case implementor & persistent model)
Mediator is the primary pattern used in the Application Model (Dialog Coordinator). I don't think that Ralph was stating that the Application Model implements use cases; I think he was saying that Mediators in general are often used for this. In fact, use case implementation is spread throughout the code, as some parts will be implemented in the Application Model and some parts in the domain model. The distinction between the two parts of the model (Application Model and Domain Model) are covered in detail in the chapter on Mediator that I wrote in the Design Patterns Smalltalk Companion.
This discussion is very interesting and quite useful, but it still doesn't address my primary question, which was who was primarily responsible for changing the meaning of the word controller.
-- Kyle Brown
This *is* interesting - I'm glad I'm not alone in struggling over all the different meanings of Model View Controller being used around the industry.
My learning experience over "who switched the name" is similar to the experiences of several people here: the responsibility in my mind is split between Ivar Jacobsen's book and NeXT's App Kit.
I think Next Step is probably more responsible than Ivar Jacobsen, if only because NeXT has been publicly around for longer than Jacobsen's book. (1989 vs 1994?) I first learned about MVC-like patterns through Jacobsen's book & NeXTStep - but got utterly confused when I read Adele Goldberg's Smalltalk-80 book. :)
-- Stu Charlton
The plot thickens... Joelle Coutaz kindly replied to an email I sent her a while back asking about the origins of the PAC architecture. She informed me that when she formulated PAC that she was unaware of MVC, and that she chose the word "control" independently. She later discovered MVC and was delighted to see the similarities, but also noted that her (independently coined) term "control" was similar to the term "controller" used with a very different meaning.
So if I could just track down who at NextSTEP originally reinterpreted the "C" in MVC to mean the "C" in PAC then I could put this thing to bed...
-- Kyle Brown
I've been using and researching MVC architectures since I first encountered it in Smalltalk at Xerox Parc. (I think the first public version containing MVC was Smalltalk-80, and it was a long time before anything was published on it - the 1988 Cookbook paper referenced above.) I remember that Stepstone's Objective Cee GUI library, from which Next Step was derived, had classes that combined C's and V's at least as early as 1987. I found that scandalous at the time, flying in the face of MVC dogma as it did, but eventually came to realize that the separation between the M and the V&C is far more important and significant than the separation between the V and the C.
Brad Cox, inventor of the Objective Cee language and a Stepstone founder, wrote in his 1986 classic Object-Oriented Programming: An Evolutionary Approach [p. 169 in the corrected first edition]:
Smalltalk's presentation layer consists of not one, but two, class hierarchies. The outgoing leg of Smalltalk's user interface is handled by a hierarchy of views much like the [View] ones discussed here. But the incoming leg is implemented by a separate hierarchy of classes, Controllers, that provide the logic for parsing cursor and keyboard actions with respect to the view to control the application. My approach differs in that each view is responsible for managing both of these channels. The need for the separate controller hierarchy is unclear and is the topic of spirited debate even within the Smalltalk-80 community [citing "Personal communications with Alan Borning, Trygve Reenskaug, Glen Krasner, and Larry Tesler"].
The advantage of having each view support a complete user interface is that it is far easier to describe and understand. But this scheme may have the disadvantage of insufficient generality to accommodate differences such as one-button versus three-button mice. It is hard to predict the extent to which differences of this kind require an additional architectural layer, or whether they can be handled through routine use of the flexibility that does exist already (e.g., inheritance, encapsulation, and virtual terminals).
The original MVC formulation separated the V and C because just as you could have several different implementations of V's displaying M's in different ways, you could have several implementations of C's for a given V (a Read Only Text Controller, Text Controller, Right To Left Text Controller, etc.) all able to manage a Text View, for instance. (I don't remember anyone ever suggesting it was useful to be able to have several implementations of V's for a given C, though - the V always seemed to be the focus of MVC.) Not only did being able to choose among C variations for a V make design and implementation more flexible, but the choice could be deferred until the interface is created, and an interface's C could be replaced dynamically (for example, when a document is changed between read-only to writable). It's also occasionally useful to be able to describe inheritance relationships among C's differently than the inheritance relationships among V's; in particular, it's sometimes possible to share a single controller class among a whole subhierarchy of view classes.
A more substantial change in the use of MVC has been its nearly complete restriction to GUI components. (See Model View Controller History.) In most GUI toolkits the M is no longer a domain object, but an intermediary such as a Visual Works Value Holder or Aspect Adapter. With the scope of MVC components so small there's no longer much need for the flexibility provided by separating V's and their C's - how many kinds of C's are there going to be for a TextField? Consequently, many modern toolkits don't bother making that distinction. That's not the same thing as saying that there isn't or shouldn't be such a distinction.
Mitchell Model wrote: I don't remember anyone ever suggesting it was useful to be able to have several implementations of V's for a given C, though
The MDPC architecture aims at doing that: one C for multiple V's, see lii-enac.fr .
Disclaimer: I'm the author of the article. I'm not sure it's fair to edit this page this way, hope it does not break any etiquette.
Perhaps you can put the research to bed, but I am left wanting for standard language. When I instruct developers about Web Application Design, do I use the convention I've grown up with (post-NeXT) or introduce a framework as implementing Presentation Abstraction Control, at the risk of causing confusion with outside sources? -- Hans Gerwitz
And just how do you spell Jacobson, anyway?
Dolphin use something called Model View Presenter. They say that controllers were more useful when Smalltalk was self-hosted. The controller did much of the low-level work of a device driver. When Smalltalk is running on top of an operating system like Windows, the controller becomes almost trivial because the OS does all the work. Further, they note certain problems with the notion of an "application model" object. The thing which represents the application has to know about the views, so should not be part of the Model (which is independent of views). Thus MVP. The Presenter knows about both View and Model, wires them together and routes input events appropriately.
Dolphin document where this approach came from. I can't now find the reference, but I think it was one of Apple's OS projects - Pink or something. I have probably explained it wrong. See Model View Presenter for links to Dolphin's documentation.
A very interesting topic. I stumbled over this subject some time ago when we designed our model driven, J2EE based development approach.
There I got the notion of a Fractal Model View Controller in our system.
My experience with MVC is of three extremely vague categories, which are only recognized after the fact, where one looks at a well-modularized system and places the function of each category into one of these roles, where Model pertains to state management, View to interface, and Controller to program logic. Controller ends up being the most vague of all these categories, and a satisfactory explanation is never given - mostly because MVC was designed for a very specific requirement in a specific environment, and is something of a square peg when it comes to describing architectures such as web apps or even event-driven GUI toolkits. As a high-level definition of roles, MVC has its uses, but attempting to reify it simply leads to madness, or at least frustration. Good design practice can succeed perfectly well regardless of whether it's MVC in one of its million varying guises, and indeed whether or not the designer is aware of the MVC design philosophy at all.
Thank you for this discussion, btw. It filled a void. The last definition I read elsewhere was totally off target; perhaps intentionally.
"Computer scientists in general have an annoying tendency to overload terms."
AND
"Good design practice can succeed perfectly well regardless of whether it's MVC in one of its million varying guises, and indeed whether or not the designer is aware of the MVC design philosophy at all."
Agreed ...
I came looking for definition and found an earnest discussion about definitions; the 'state' of homonymic concepts.
Perhaps a band of disenfrachised 'Three Amigo' wannabees have become standardless vigilantes on the open frontier. The lack of structured communication and deposition of formal definitions brings confusion to meaning. What began as deterministic science has morphed into new-speak adnauseum, exchanging science for conjecture and lack of order. Do we dialog with parallel contexts using similar terms, or do we fill variants with interlingual proposals, hoping that meaning will eventually evolve through use and acceptance?
Having begun programming in the dark ages of machine language, I have witnessed forks in the modeling concept universe, some taking viterbi-like approximations that terminate in useless convolution; over-descriptions of simple or correct solutions. The bottom line is that too many engineers ask me in private how to initialize object data ... they can't even make the first round on the game board because they are so confused. I have to hide the "Go to Jail" cards out of compassion. Most of the time, most of the information these fellows try to digest will never apply to the problem set at hand. They JAVA their way into C++ and try to Small Talk BASIC details ... and then they propose new acronyms! Meanwhile, managers wonder why projects take so long, and good designs are shelved as mere prototypes awaiting realization by a dull committee for lack of approved stereotypes that they can't implement anyway.
Perhaps we need a concept translation table with history, contexts (applicable languages and platforms) and state for every acronym proposed and utilized in our profession (Here we see a microcosm of it). Imagine drop-in objects and controllers ... reusability and well-worn code; reliable systems with terse architectures. Scratch that ... it accommodates more outsourcing to illiterates. -- db
I would like to move db's comment to a new page - Computer Speak - but I will wait a while to see what you think. -- Peter Lynch
One Important advantage I see in having separate V and C is for Unit Testing... when I code C, I do it in a way that completely hides the presentation technology (no references to the view framework (ASP.NET, Windows Forms.NET, Swing, Flex)); in that way, I can write tests that work directly with the controller... I can even write them before I have written the code for the view... and I can test my control logic independently of view issues (that way, it is easier to isolate bugs, because I know that if all my Control Unit Tests passed, the more likely place for the source of a bug is in the View code (and the view code is always the hardest to Unit Test). This separation makes it real easy to reutilize my control logic between Web Clients and Heavy Clients that implement the same (or similar) use cases. (It is very useful for times when your boss tells you Okay, that is a great Windows Forms.NET application... and it works great in our intranet, but now, we want the uses cases 1,2,3,4 to be available over the internet for users of any platform.
I really really dislike the fact that most of the new visual applications builders just don't have an integrated way to introduce the concept of view independent controller... without it you end up with code mixing view and control issues that make it a lot harder to hande UI changes that shouldn't affect you code that much... some examples of that are:
A Combo Box and a Radio Button are the same thing they are Visual Controls For To One Relationships
A Grid View might be a Visual Controls For To One Relationships or a Visual Controls For To Many Relationships depending on its configuration
A Tree View might be a Visual Controls For To One Relationships or a Visual Controls For To Many Relationships depending on its configuration
You should be able to switch between these controls, as long as you don't hurt the multiplicity relations, without having to worry about having to touch your control code... if you have a method you control that returns and array... and you know you can only select one element (and have a method in you controller to say what element you selected), I think you should be able to switch between View Controls For Relationships with the same multiplicity in a completely isolated way.
That's perhaps lack of dynamism (or its influence) in the language or GUI kit. See Inappropriate Type Checking -- top
I've always thought of the controller in the video game sense. If you're playing a submarine simulator, you could control it with hotkeys on the keyboard, with a mouse, joystick, gamepad, or steering wheel and pedals. You could have a command-line style interface where you type orders to the ship's crew as complete sentences or an audio interface where you speak them into a microphone. Or some combination of the above. The view shouldn't care, nor should the model. It's the job of the controller to validate and translate the input, however it comes in, into a standard set of messages or events that can be dispatched to the model. Whether you twitch the joystick, tap the left arrow key, or say "Left full rudder", the result on the view and model should be the same.
Good for games, but nobody does word processing with a joystick, or spreadsheets with a gamepad. So is a separate controller layer needed for business apps? Well, a controller layer allows the user to use their choice of menus, hotkeys, toolbars, macros, scripting, etc., without having everything hard-coded and/or duplicated. As in the game, generally neither the view nor the model should care where the command comes from. An order in a web shopping cart usually shouldn't care whether you clicked the "Priority shipping" radio button, selected it in a dropdown, passed it in the URL, or an API call. It just needs to know that you want priority shipping on that order. That level of flexibility isn't always needed, but it's useful, and very distinct from the model-to-view glue code (that's mostly about formatting and rendering) in my mind.
I could be wrong, but I assume that's what was meant by the original definition. I never noticed the confusing part of "contain the interface between their associated models and views and the input devices".
I don't speak Small Talk, then I only can make some assumptions for implementations of the MVC original implementation.
In these days, with event-driven environments all over, the old notion of a Controller is covered by event-handlers, highly coupled with the View in many implementations. If different Views have different presentation gadgets then it derives into different event handlers (Controllers?). If the Controller and the View are tightly coupled as this, the reusability of the different layers (CV) is impossible. Also the Controller isn't a real layer in this scenario.
My view of a Controller is more like and Application Layer (or Model) that defines the implementation of use cases scenarios. The event-handlers or calls from the View are directed to the Controller use case scenario implementation. Then, the whole set of Controllers (the Application Layer) can be completely independent of Views. The set of Controllers can be used with different Views any time. The Controller connects with the Model and other lower sub-systems to fulfill the tasks.
How the Controller in this version can communicate with the View to show the Model updates? The View should pass data as parameters (usually an abstraction of the View itself or any helper abstract class that resemble it) in the message for the Controller. The Controller can have return values or change the parameters sent that the View must check to update the presentation.
I define the Model as a Domain Layer. The Model represents entities in the real world, not implementations of it in tables or related persistent objects (common vision these Microsoft days). The Controller manages the Persistence (using a persistence sub-system preferable) of the Model based on data that the View has sent with the specific message.
These way I can use or test another set of domain classes (Model) or adapt another one, only affecting the Controller implementation, not persistence nor Views (of course if the interface are similar or an Adapter is possible).
Maybe the above comments doesn't add any valuable information of the origin of the change of the Controller concept, but I think add some vision of it in event-driven environments.
--Claudio Rivera
See original on c2.com