The World Needs More Models
Canoo’s CTO Bruno Schäffer is speaking at SD West 08 on “Design Patterns for Rich Internet Applications”.
The following blog post outlines some of the concepts that he will cover in his talk. This is part two of a series of blog posts:
In part one we discussed why plain MVC is not suited for Rich Internet Applications. The presentation model extends MVC to better fit the needs of applications with complex presentation logic. Martin Fowler first described the basic idea of this approach. The presentation model inserts an additional model between the business model (i.e. business object) and the view-controller duo. It captures the state of the user interface and handles the presentation logic. The business object is not directly accessible to the view anymore. The presentation model offers only those business object properties to the view that are relevant to rendering the user interface. The presentation model may map the properties of several business objects. If the business object does not serve as the model in MVC, it does not need to provide any observer infrastructure and can stay a real POJO.
In traditional MVC you have either equip the business object with some observer infrastructure, employ some kind of decorator for the business object which handles view notifications (e.g. a dynamic proxy) or define an aspect.
What state must be captured by the presentation model? Basically, it is the entire mutable state of the user interface. For example, the mutable state of a checkbox is whether it is
- selected/not selected,
- and enabled/not enabled
(visibility might be another relevant state). The background color of a checkbox is not relevant to most UIs and hence not a mutable property which needs to be captured by the presentation model. Complex state such as a table model or tree model can easily be delegated to a sub-presentation model. Common UI toolkits provide default implementations for these models so there is no need to re-implement them in the presentation model.
Now, how does the view react to changes in the presentation model? It is pretty simple: the presentation model is fully observable and the view gets notified of the changes by the observer pattern. This approach can even cover non-trivial scenarios, such as the following one:
The user just selected a different row in the table and the user interface has now ask the user whether any modifications should be saved. Changing the selection state is a responsibility of the presentation model. However, the presentation model is not supposed to directly pop up a dialog, but it can trigger an update event and the responsible view will react to that by displaying the dialog. The action buttons in the dialog will then call the appropriate methods in the presentation model.
The observer pattern not only provides broadcast communication among classes but it also helps to decouple classes. On the other hand, one has to be aware of its drawbacks. In languages with static type checking it may circumvent the type checking by relying on a generic update method. Debugging also tends to be harder since one has to step through the observer infrastructure. In addition, trying to understand code with nested listeners (i.e. update listeners which themselves trigger update events again) is not really fun. At least try to avoid updating properties within a bean by means of the observer pattern.
At start-up time the view needs to get the entire presentation state in order to render the initial state of the user interface. For this, the presentation model can trigger update events for all its properties.
With the presentation model it is now clear to developers where to put all the presentation logic and therefore the implementation is more straightforward and uniform. Another big advantage is improved testability. As I mentioned in take one, automatic testing of user interfaces is expensive both at development and run-time. The presentation model substantially improves this situation. Most UI testing can be accomplished by just developing and executing unit tests on the presentation model without the need to run the user interface. These tests are way easier to implement since they only change properties of the presentation model and test properties resp. update events.
Since the presentation model covers most of the former responsibilities - what remains to be done for the view? Part three “A Simple View on Complex Stuff” will discuss this. We will also look at a simple example. Stay tuned!
