As is evident from the discussion of WhatsaControllerAnyway, the connotations of the acronym "MVC" and the term "ModelViewController" 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 ModelViewControllerHistory). 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 JavaServerPages "Model 2" architectures). The implication is that there have always been two kinds of model: DomainModel, and ApplicationModel. 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) JournalOfObjectOrientedProgramming 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 InspectorView 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 ApplicationModel in the VisualWorks 1.0 release of Smalltalk-80. For further documentation of the implication and distinction, see p.290 of KyleBrown and BobbyWoolf's DesignPatternsSmalltalkCompanion, and the literature reference fanout from that page. See also AdeleGoldberg's foreword to TimHoward's TheSmalltalkDevelopersGuideToVisualWorks, in which she confirms that ApplicationModel''''''s support linking a DomainModel 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 WhatsaControllerAnyway, and to be aware that ModelViewController often means ModelModelViewController 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 ApplicationModel''''''s in ModelModelViewController architecture. --RandyStafford ---- 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 ValueModel''''''s. However an Adaptor or "model interface" is '''not''' an ApplicationModel. Instead, in Smalltalk, an ApplicationModel 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 ApplicationModel''''''s. --RandyStafford'' ---- RichardMacDonald 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 PartyOfFive talk about PresentationAbstractionControl, where (roughly) Presentation is View, Abstraction is DomainModel, and Control is ApplicationModel. --RandyStafford'' 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 http://www.object-arts.com/DolphinSmalltalk.htm). --PaulMitchellGears Here is a document on Model-View-Presenter: http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm MVC vs MVP: http://www.darronschall.com/weblog/archives/000113.cfm And now, MGM (Model-GUI-Mediator)? I sense some buzz. http://www.atug.com/andypatterns/mgm.htm --LyndonTremblay ----- "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 JavaServerPages 'Model 2' architectures)." ''Definitely an abuse of the term - there are at least two or three antipatterns in JSP/STRUTS/etc. (including WagTheDogAntiPattern) that violate (what I see as) the spirit of MVC.'' -- TomRossen ---- See also: MvcInJspModelTwoArchitecture