Model View Controller (MVC)
Windows programmers generally start learning application development by creating form(s), dropping controls on them and wiring-up the controls events. The form(s) will consist of a visual component and its associated code which we call “code-behind”. Where this is convenient for very small applications it doesn’t lend itself to reuse or extensibility. MVC addressed the issues of reusability and pluggabity with a three way separation of the parts that represent the model of the application domain, the way the model is presented to the user and the way the user interacts with it.
MVC was conceived as a solution to the problem of handling large and complex data sets. Trygve Mikkjel Heyerdahl Reenskaug, a Norwegian computer scientist, created the Thing-Model-View-Editor pattern in 1978 while visiting PARC (Xerox Palo Alto Research Center). The first implementation had a model, view, controller and editor where the editor was a component created by the view on demand as a interface between the view and the input devices. Thing-Model-View-Editor was later renamed Model-View-Controller. After Trygve left Xerox PARC, Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library.
MVC was not used for Smalltalk-80 in the manner it was originally conceived; Trygve noted that Jim Althoff used the term controller differently then he did; for Trygve the controller was responsible for “creating and coordinating its subordinate views and handled input relevant to the controller/view assembly. Smalltalk-80 defines MVC as follows:
The model of an application is the domain-specific software simulation or implementation of the application’s central structure. This can be as simple as an integer (as the model of a counter) or string (as the model of a text editor), or it can be a complex object that is an instance of a subclass of some Smalltalk-80 collection or other composite class. Several examples of models will be discussed in the following sections of this paper.
Views deal with everything graphical; they request data from their model, and display the data. They contain not only the components needed for displaying but can also contain subviews and be contained within superviews. The superview provides ability to perform graphical transformations, windowing, and clipping, between the levels of this subview/superview hierarchy. Display messages are often passed from the top-level view (the standard system view of the application window) through to the subviews (the view objects used in the subviews of the tool view).
Controllers contain the interface between their associated models and views and the input devices (keyboard, pointing device, time). Controllers also deal with scheduling interactions with other view-controller pairs: they track mouse movement between application views, and implement messages for mouse button activity and input from the input sensor. Although menus can be thought of as view-controller pairs, they are more typically considered input devices, and therefore are in the realm of controllers.”
MVC continued to evolve to solve problems such as separating visual state from domain objects and allowing the model to update the view directly (which contradicts early principles of MVC). While still being called MVC the underlying responsibilities of the model changed within the Triad; as a result the models name would be changed to Presentation Model or Application Model Martin Fowler, in his GUI Architectures document, describes the Presentation Model which shares most of the same concepts of the Application Model with the exception of being able to update the view directly (which is not part of the Presentation Model).
Martin Fowler, also states in his GUI Architectures document that “Different people reading about MVC in different places take different ideas from it and describe these as ‘MVC'”; he later states “it’s also the most misquoted (pattern)“. I contribute the cause of the misunderstandings to modern day developers not having a common core of experience with the early developers/architects; our environments are totally different and many of us have always worked with smart controls (I’ve been programming for over 20 years).
To effectively understand MVC, today’s developers should understand that smart controls made the controller in MVC obsolete. The authors of “Twisting the Triad” note the following: “the idea of a controller did not fit neatly into the Windows environment. Microsoft Windows, like most modern graphical operating systems, provides a set of native widgets from which user interfaces can be constructed. These “windows” already include most of the controller functionality embodied as part of the underlying operating system control.“. Martin Fowler states “parts of classic MVC don’t really make sense for rich clients these days”
MVC doesn’t apply to smart controls since they don’t require a controller (gestures and events are handled by control)
Before we continue we have to have a clear understanding of what “gestures and events” are within the context of the MVC environment; since our smart controls handle these for us we may not be familiar with these terms and could make assumptions. Gestures are button clicks, key clicks, selecting a menu-item/Window, etc. Gestures trigger a function to carry out a task asychronously. If the program is busy when the gesture occurred it will be put on a queue of events until the application can handle it. With smart controls, gestures and the event loop function are handled for us under the hood; we simply subscribe to events, i.e., Click, MouseDown, etc and point to a method that will handle it.
The following paragraphs are an excerpt from the “How to use Model-View-Controller” by Steve Burbeck, Ph.D:
Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling. A view’s instance variable controller points at its controller, and a controller’s instance variable view points at its associated view. And, because both must communicate with their model, each has an instance variable model which points to the model object. So, although the model is limited to sending self changed:, both the view and the controller can send messages directly to each other and to their model.
The View takes responsibility for establishing this intercommunication within a given MVC triad. When the View receives the message model:controller:, it registers itself as a dependent of the model, sets its controller instance variable to point to the controller, and sends the message view: self to the controller so that the controller can set its view instance variable. The View also takes responsibility for undoing these connections. View release causes it to remove itself as a dependent of the model, send the message release to the controller, and then send release to any subViews
In MVC the view’s responsibility is to display the data held by the model object, our view will display the Image and Label from the model while using the IsLabelDisplayed value to determine whether the textblock (under the image) is visible. The View has knowledge of its model but is loosely coupled (could be tied to any model with these property values); it has no knowledge of our SmileyModel class. Unlike the model, the controller is unique to its view and visa versa – our SmileyView is tightly bound to our SmileyController (line 13 below).
Above we define the “Template” (our view) for the SmileyController (lines 10-22). The SmileyController is used in the LeftPanelView and RightPanelView (the two views with Smileys) with the results being show in in the ResultsPanelView (far right view which was added later).
Below we show the source for the LeftPanelView, note that on line 24 below we instantiating a SmileyController by placing it as an element in the StackPanel. WPF will search for a ControlTemplate, find it above and execute the OnApplyTemplate() method of the SmileyController providing a reference to itself (see code snippet below the following image). This effectively permits the controller to wire-up the View’s “gestures” so that they can be processed by the SmileyController.
Consistent with MVC, our controller’s only responsibility is to handle gestures and events, in our case the gestures will be the mouse hover (icon changed to a hand) and the click event (to start process). The view/controller’s both know about the existence of the model but not visa versa.
The Model (and Smiley MVC overview)
Below we show the final component of our Smiley triad – the model which represents the data underlying the object”. In MVC, the model (Application Model) is responsible for handling application logic, communicating between domain objects and the view/controller. As such, our model holds the application logic for our Smiley triad. If we wanted to persist the model values so that we could later retrieve them it would be the model that would contain the logic to do so.
If you’ll examine the ImageMouseDown code within the SmileyModel you’ll find that it changes the image, updates the model to reflect the new state and raises the SmileyStateChanged event. Note that the LeftPanelView is setting the IsTextDisplayed property to False (line 24 of Fig 5.); this will prevent the Smiley state text from showing underneath the Smiley image. Instead the LeftPanelView will display the content above the image (reference Binding on line 19 of Fig 5.)
Our view is bound to the model and “accesses the data from the model and specifies how the data from the model is drawn on the screen” via data binding.
The controller processes user gestures (clicks) and changes the underlying data (on the model); the model will then close the loop by notifying the view that it’s state has changed via the NotifyPropertyChanged event. I should emphasize that the controller only handles gestures and events, you’ll find the Smiley controller has no application logic.
MVC Emotion Manager Demo (closing note/point)
So now we have a tri-state smiley control that can be easily reused. If Microsoft were to come out with a Smiley control our controller would no longer be needed; it would effectively render the Model-View-Controller pattern useless to us.
The SmileyController’s gestures and SmileyModel application logic would be handled by the new control so all we would have to do is wire-up the new View to a Model that contained the applicable properties.
MVC had issues which had early architects looking for a better pattern.
- Smart Controls – made the MVC pattern obsolete
- Updating the view – in our Smiley triad we had a business requirement to change the background color based on the state of the smiley icon (green=happy, blue=confused and pink=unhappy). Since the the model, which handles the application logic, has no knowledge of the view it is forced to follow MVC conventions by triggering an event passing the color with it. Our WPF Emotion Manager demo used a Dependency Property which in essence follows that convention.
- Polluting domain objects – a color is not part of the domain however it has to be on our domain object (model) for processing.
Both Taligent and the Dolphin Smalltalk teams uncovered the same weaknesses (some noted above) and solved the problem by rotating (twisting) the triad 60 degrees. MVC would evolve so dramatically that it would now be called Model-View-Presenter (MVP)
- ^ GUI Architectures, by Martin Fowler.
- ^ Twisting the Triad, by Andy Bower, Blair McGlashan
- ^ MVP: Model-View-Presenter by Mike Potel, the “Potel paper”
- ^ How to use Model-View-Controller (MVC) by Steve Burbeck, Ph.D.
- ^ An Introduction to GUI Programming with UIL and Motif
- ^ MVC Xerox PARC 1978-1979, by Trygve Reeskaug
- ^ Models-Views-Controllers, by Trygve Reenskaug
- ^ A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System, by Glenn E. Krasner and Stephen T.Pope
- ^ PresentationModel and WPF, by John Gossman