Excursus: Presentation Model Pattern

Note: This post is a preparation post for an upcoming MVVM related post (which got definitely too long)….

The Presentation Model pattern goes back to Fowler ([Fowler-PM]). What makes it relevant for Silverlight development is that it is often cited as the underlying pattern for the Model-View-ViewModel pattern.

Essentially the Presentation Model pattern contains View, Presentation Model (PM) and Model. And it actually comes in two flavors: “An important implementation detail of Presentation Model is whether the View should reference the Presentation Model or the Presentation Model should reference the View. Both implementations provide pros and cons.” ([Fowler-PM])

Interesting (but irrelevant for this post): “A Presentation Model that references a view generally maintains the synchronization code in the Presentation Model. […] The views implement interfaces allowing for easy stubbing when testing the Presentation Model.” 
This leads straight to the Passive View incarnation of the MVP pattern, also supported by the WCSF. The other incarnation of MVP is the Supervising Controller (which will be the topic of another post). The pattern ecosystem certainly has some relations…

Now, the View referencing the PM (Fowler explicitly mentions databinding) leads to MVVM/PM. Given Fowlers rejection of DTO’s its fair to assume that he had a Model constituted as BO’s in mind, with the BO’s talking directly to the next layer. However, I’ll skip that and stay with DTO’s as Model. Personal opinions aside, the common case with SL applications is using code generated service proxies, especially the service contract, as Model.

Hence the relationship of the participants in an SL application would look like this:

Fowler states it himself: “The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window,” ([Fowler-PM]), meaning that the PM constitutes its own data model, and the View does not get access to the Model.

This is actually the defining characteristic of the PM pattern: The PM provides – constitutes – is – a data model, separate from the Model; the View is shielded away from the Model and doesn’t get access to it or its types. (It consequently follows that the pattern requires a duplication of the data model – hence the name Presentation Model – that is largely readily available with the Model.)

Thus the PM has several responsibilities:

• Defining its own data model
• Mapping the data between the two data models (using wrappers or other means)
• Handling the controller logic part
• Talking to the service (with BO’s rather than DTO’s, it would be their job to do this).

The Relation to MVVM

John Gossman’s post “Introduction to Model/View/ViewModel pattern for building WPF apps” (written 2005!) is generally referred to as the “introducing post”, bringing MVVM into existence. If only somewhat between the lines, but he introduces and defines MVVM as derivate of the PM pattern (without actually naming it); Wikipedia declares MVVM “as a specialization of the PresentationModel design pattern”, and the often quoted MSDN article “WPF Apps With The Model-View-ViewModel Design Pattern” follows the same principles.

Hence MVVM also suffers from the need to replicate the data model. John Gossman states that “only a small subset of application UI can be data bound directly to the Model“, and thus it is feasible to pay for this effort and the implications. However, if you don’t agree with this assessment (like me, for one), you could argue that this leads to meaningless replication.

Note: Fowler actually acknowledges that and states: “One area where data binding can work very well is with read-only data, […] The presentation model in this case reveals its internal data set as a property. This allows the form to data bind directly to the cells in the data set.”

However, this is a shortcut (kind of a degeneration) for read-only cases, in order to leverage data binding capabilities.

And by the way: If this is not exactly what you do if you say “I do Silverlight with MVVM…”, welcome to the club. That’s what started this post in the first place. More on this in the next posts…

That’s all for now folks,
AJ.NET

Advertisement