Model Model View Controller

As is evident from the discussion of Whatsa Controller Anyway, the connotations of the acronym "MVC" and the term "Model View Controller" have lost precision over the years, as their usage has increased outside the Smalltalk community in which the namesake behavior-partitioning paradigm was invented (see Model View Controller History).

However, even within the original precise Smalltalk connotation of MVC, there is an implication not obviously conveyed by the term, and certainly not appreciated by people that use the terminology so freely today (e.g., people in the J2EE community, describing Java Server Pages "Model 2" architectures).

The implication is that there have always been two kinds of model: Domain Model, and Application Model. Hence the name of this page. The evidence is clear, and the documentation plentiful. Consider the following, from Krasner & Pope's original (August/September 1988) Journal Of Object Oriented Programming article titled "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80".

The inspectors in the system are implemented as two views. ... An instance of Inspector View serves as their common superview ... The model for these views is an instance of Inspector. Inspectors can be used to view any object. A separate class, Inspector, serves as the intermediary ... Using intermediary objects between views and "actual" models is a common way to further isolate the viewing behavior from the modeling application.

Thus the "actual" model is the object being inspected, and the Inspector is the application model. The concept of an application model was finally reified by class Application Model in the Visual Works 1.0 release of Smalltalk-80.

For further documentation of the implication and distinction, see p.290 of Kyle Brown and Bobby Woolf's Design Patterns Smalltalk Companion, and the literature reference fanout from that page. See also Adele Goldberg's foreword to Tim Howard's The Smalltalk Developers Guide To Visual Works, in which she confirms that Application Models support linking a Domain Model to application logic that uses it.

So what, you say. Well, here's what. As a point of general principle, people who talk about MVC architecture (such as people in the J2EE and JSP communities) should take it upon themselves to understand the historical meaning and implications of the terms they use, so as to eliminate confusion about Whatsa Controller Anyway, and to be aware that Model View Controller often means Model Model View Controller in the original Smalltalk implementation of the paradigm. In fact, a case could probably be made that many of the responsibilities allocated to the "controller" (in the Jacobsonian connotation of the term) were probably allocated to Application Models in Model Model View Controller architecture.


How does this relate to the model interfaces defined for each GUI component in the Java Swing framework?

The closest Smalltalk analogy to the Swing component "model interface" is probably the concept of an Adaptor, whose job it is to adapt the interface of a (domain) model to the interface expected by a view component. In Smalltalk, Adaptors are typically Value Models. However an Adaptor or "model interface" is not an Application Model. Instead, in Smalltalk, an Application Model is usually reponsible for instantiating an Adaptor and binding it to the view component and (domain) model. In a Swing UI, this responsibility typically falls on a Panel (or Frame). So, in a Swing UI, Panels (and Frames) form Application Models. --Randy Stafford


Richard Mac Donald posts on comp.object about MVP: model view presentation, where the presentation sits between the model and view (who don't know about each other). It sounds similar to application model defined here -- an isolation layer.

Yes, it does sound similar. Is there any literature on the MVP idea? There seems to be a lot of different terminology in this area - for example, the Party Of Five talk about Presentation Abstraction Control, where (roughly) Presentation is View, Abstraction is Domain Model, and Control is Application Model. --Randy Stafford

Yes, Dolphin Smalltalk (at least the free version) uses this paradigm and explains/discusses it at length in the bundled docs, which are with the download and may be available on the web as they are HTML (try poking around at www.object-arts.com ). --Paul Mitchell Gears

Here is a document on Model-View-Presenter: www.object-arts.com MVC vs MVP: www.darronschall.com And now, MGM (Model-GUI-Mediator)? I sense some buzz. www.atug.com


"However, even within the original precise Smalltalk connotation of MVC, there is an implication not obviously conveyed by the term, and certainly not appreciated by people that use the terminology so freely today (e.g., people in the J2EE community, describing Java Server Pages 'Model 2' architectures)."

Definitely an abuse of the term - there are at least two or three antipatterns in JSP/STRUTS/etc. (including Wag The Dog Anti Pattern) that violate (what I see as) the spirit of MVC. -- Tom Rossen


See original on c2.com