Twisting The Triad

VisualBasic, IS/2 등에 해당.

with a widget-based system it is easy to avoid having to think about the (required) separation between the user interface and the application domain objects, but it is all too easy to allow one's domain code to become inextricably linked with the general interface logic.

it was much more that the widget system was just not flexible enought. We didn't know at the time, but were just starting to realise, that Smalltalk thrives on plugability and the user interface components in out widget framework were just not fine-grained enough.

One example of this deficiency surfaced in SmalltalkWorkspace widget. This was originally designed as a multiline text-editing component with additional logic to handle user interface commands such as Do-it, Show-it, Inspect-it etc. The view itself was a standard Windows text control and we just attached code to it to handle the workspace functionality. However, we soon discovered that we also wanted to have a rich text workspace widget too. Typically the implementation of this would have required the duplication of the workspace logic from the SmalltalkWorkspace component or, at least, an unwarranted refactoring session. It seemed to us that the widget framework could well do with some refactoring itself!

In MVC, most of the application functionality must be built into a model class known as an Application Model. It is the reponsibility of the application model to be the mediator between the true domain objects and the views and their controllers. The views are responsible for displaying the domain data while the controller handle the raw usr gestures that will eventually perform action on this data. So the application model typically has method to perform menu command actions, push buttons actions and general validation on the data that it manages. Nearly all of the application logic will reside in the application model classes. However, because the application model's role is that of a go-between, it is at times necessary for it to gain access to the user interface directly but, because of the Observer relationship betweeen it and the view/controller, this sort of access is discouraged.

For example, let's say one wants to explicitly change the colour of one or more views dependent on some conditions in the application model. The correct way to do this in MVC would be to trigger some sort of event, passing the colour along with it. Behaviour would then have to be coded in the view to "hang off" this event and to apply the colour change whenever the event was triggered. This is a rather circuitous route to achieving this simple functionality and typically it would be avoided by taking a shoutcut and using #componentAt : to look up a particular named view from the application model and to apply the colour change to the view directly. However, any direct access of a view like this breaks the MVC dictum that the model should know nothing about the views to which it is connected. If nothing else, this sort of activity surely breaks the possibility of allowing multiple views onto a model, which must be the reason behind using the Observer pattern in MVC in the first place.

Model
This is the data upon which the user interface will operate. It is typically a domain object and the intention is that such objects should have no knowledge of the user interface. Here the M in MVP differs from the M in MVC. As mentioned above, the latter is actually an Application Model, which holds onto aspects of the domain data but also implements the user interface to manupulate it. In MVP, the model is purely a domain object and there is no expectation of (or link to) the user interface at all.

View
The behaviour of a view in MVP is much the same as in MVC. It is the view's responsibility to display the contents of a model. The model is expected to trigger appropriate change notification whenever its data is modified and these allow the view to "hang off" the model following the standard Observer pattern. In the same way as MVC does, this allows multiple vies to be connected to a single model.

One significant difference in MVP is the removal of the controller. Instead, the view is expected to handle the raw user interface events generated by the operating system (in Windows these come in as WM_xxxx messages) and this way of working fits more naturally into the style of most modern operating systems. In some cases, as a TextView, the user input is handled directly by the view and used to make changes to the model data. However, in most cases the user input events are actually routed via the presenter and it is this which becomes responsible for how the model gets changed.

Presenter
While it is the view's responsibility to display model data it is the presenter that governs how the model can be manipulated and changed by the user interface. This is where the heart of an application's behaviour resides. In many ways, a MVP presenter is equivalent to the application model in MVC; most of the code dealing with how a user interface works is built into a presenter class. The main difference is that a presenter is directly linked to its associated view so that the two can closely collaborate in their roles of supplying the user interface for a particular model.

Compared with our orignnal widget framework, MVP offers a much greater separation between the visual presentation of an interface and the code required to implement the interface functionality. The latter resides in one or more presenter classes that are coded as normal using a standard class browser.