Augmenting view model

So far, we have assumed that view can use the state of domain model for presentation. This assumption gets challenged pretty soon because of mismatch between presentation and domain model. These differ with each other in various ways. Lets look at these differences through examples.

View state represented by objects holding more information than present in domain model

Along with filling a form the user is expected to tick the term and conditions check box. While the form data is fits into the domain model the check box state is meant solely for view.

Format of view data is different from that in domain model

Phone numbers might be represented just as a number in customer object but it is displayed as +91 80 4343 4343 to the customer service representative.

Multiple fields from a domain object might be merged together during display

The customer's name in domain model is stored as firstName, lastName and title. The views displays this information as "Mr. John Smith" in a single field.

List with placeholder options

In a combo box showing the list of countries the view displays additional "Select One" option to assist the user.

To get around these issues, domain model is augmented by a view model. This view model is the object from which the view reads its data. A augmenting view model doesn't redefine data which is already present in domain model, instead reuses it. A augmenting view model is constructed by the controller along with the domain objects. The binding model exposes the domain objects directly so that view can bind to it. When the data in domain model needs to be transformed or formatted in some way view model decorates it. The crucial aspect of augmenting view model is that it reuses the domain model. Quite often a view model is used such that it exactly represents the presentation data. Although it is a simple approach it does introduce significant amount of work of re-definition and mapping of view model from domain model, even when no additional value is added by view model.

<CODE SAMPLE>

The code illustrates the pattern but there are two underlying design principles which needs to be stated explicitly as its not apparent.

1. Domain model should be agnostic of presentation Domain model is responsible for implementing business logic and it should not be saddled with additional responsibility of presentation. Following this, as in the code above, the domain model is used for presentation but it doesn't do anything specifically for the view apart form exposing the asked data for.
2. View code should be dumb A dumb view makes it easier to collaborate with user interface designers allowing to focus on what they are good at. Most software teams don't have the luxury of UI designers but keeping UI dump is useful for another reason, testability. User interfaces are one of most difficult to unit test and a dumb view principle makes sure that view is not holding on to code.

Decoupled domain model illustrates situations when this pattern might not be suitable. These can be when the application layer chooses to encapsulate the domain objects from its clients.