AJ's blog

January 1, 2010

MVVM needs (re)definition

Filed under: .NET, Silverlight, Software Architecture — ajdotnet @ 3:41 pm

So, the last two posts made the point of showing that MVVM has a rather fragile theoretical foundation. Either that, or it is constantly misapplied.

Matter of fact, there are two incarnations of MVVM. In order to distinguish them, let’s call them MVVM/PM and MVVM/SC respectively.

As a quick recap: The relevant difference between the Presentation Model pattern and the Supervising Controller Patter (and the MVVM derivates respectively) is whether the View gets access to the Model’s data model or not. The patterns are very similar, but they differ in this one important aspect.

See my preparatory posts for details. Another descriptions of the two patterns with the same distinction can be found in the Composite Application Guidance for WPF and Silverlight documentation.

One could argue that this difference is superficial, even that Supervising Controller is actually a special case of Presentation Model (if you promote Fowlers exception for read-only data to the be the norm). In fact, when I discussed this whole topic with other people, about half of them fell into the camp that didn’t care at all and rather took the pragmatic approach, like “Who cares, I use MVVM the way it suites me, no matter what some useless theoretician thinks I should be doing.”. But even they didn’t argue the fact that there actually is something wrong with the theory.

The Problem with the Theory…

Theoretical musings aside – and presuming we agree that there are two different MVVM patterns – why is that a problem?

Well, I see several problems:

First, if someone tells you, he is using MVVM, he communicates something.

This is the most important achievement of the GoF with their groundbreaking work on patterns: Simply by providing a catalogue of abstract relationships of software artifacts and naming them, they established a vocabulary. This vocabulary is a means of communication, a way of talking about abstract concepts. What this has done to foster knowledge reuse, software quality, and documentation aspects can hardly be underestimated.

However, having a term with contradictory meanings will destroy that means perhaps more severely than not having a respective term in the first place.

Second, having a solid theoretical foundation, a clear concept, leads to a better understanding in general.

It is the concept that guides me if I have to face a situation that is not really addressed by the current implementation. And implementation has to follow the concept, not vice versa.

If I know what the theoretical foundation is, it can help me answering certain questions. Or it can tell me clearly that a particular topic isn’t covered by this pattern, hence I will know that I’ll have to look elsewhere. Without a solid foundation I won’t get any guidance, I would have to solve every problem on my own, and I would be in danger of violating principles that I’m not even aware of.

Third, on the practical side, we need to clarify the theoretical foundation to tackle the actual issue: Neither approach does actually help by itself.

As an example take validation. Validation in SL3 works by putting validation code into property setters or applying validation attributes to them. However, neither option is feasible with the code generated service proxy classes. Alternative approaches I found, like attaching code to the property changed event, are not very satisfying to say the least. Other demands include thoughts about generic caching or offline support.

  • MVVM/PM solves this issue quite easily within the PM. But having to replicate the data model leads to a maintenance nightmare. And (at least in the Silverlight area) it’s hardly employed, anyway.
  • MVVM/SC (the usually employed pattern because it works very well with the tooling) simply stops short of answering questions regarding validation.

Actually it has been the issue of validation and thoughts about caching and offline support that triggered all these thoughts and sent me back to the drawing board, investigating the concept, and trying to find out what the theory tells me. Well, I found two different MVVMs…


So, I did wreck MVVM, didn’t I? Sorry. Couldn’t be helped.

In my opinion, the only solution for this mess is a redefinition of the term MVVM. This in inevitable, I’m just not sure how this will happen. The concept could evolve and form a better theoretical foundation. But then, people could also continue to neglect the theory and come up with “pragmatic solutions” – meaning that MVVM becomes a fancy umbrella term for anything that looks remotely like PM or SC.

Personally, I would certainly prefer a sound theoretical foundation, probably one that emancipates MVVM from its two parents. Actually I would go where the tooling goes (see Dan’s post), because this is what people will do in the long run, and with good reason. Thus I would start with MVVM/SC as MVVM. From there I would either extend MVVM or complement it with other patterns to address validation, caching, synchronization for offline applications, whatever.

Yes, this would imply redefining MVVM to stem from SC rather than PM, and to accept VM as misnomer for the sake of continuity. And additional concepts to fill the gaps, that may yet have to evolve. However, this is what people think they are doing, anyway. It’s simpler to adjust the theory than people’s perceptions.

One important note: I deliberately ignored WPF! While MVVM started there and was reused with SL, it may be the case that the special demands of an SL application may cause MVVM to evolve differently for the two technologies. (It may not. Still, I’d like to keep that door open.)

So far my criticism. I’m aware that I just redefined (or rather dumped?) a well-established term, and I’m not someone like Fowler who does that on a daily basis. So I would be interested in opinions. Just tell me if I went over the top.

That’s all for now folks,

kick it on DotNetKicks.com


Excursus: Supervising Controller Pattern

Filed under: .NET, Silverlight, Software Architecture — ajdotnet @ 3:35 pm

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

The Supervising Controller pattern (previously known as Supervising Presenter pattern) goes back to Fowler ([Fowler-SC]). What makes it relevant for Silverlight development is that it is the usually employed pattern.

Similarly to the Presentation Model (PM) pattern, the Supervising Controller pattern essentially contains three parts: View, Model, and Supervising Controller (SC). The SC pattern provides “the ability to easily map between the view and model, often using some kind of Data Binding”. The mediator between the View and the Model is the SC: “A Supervising Controller has two primary responsibilities: input response and partial view/model synchronization.” ([Fowler-SC])

While the SC pattern is very similar to the PM pattern, the relationship and responsibilities of the parts are somewhat different. For an SL application it looks like this:


Compared with the PM pattern, the difference is seemingly minor: The SC lacks the responsibility to establish a data model, rather there is an additional arrow from View to Model. However, this is actually (at least in comparison to the PM pattern) the defining characteristic of the SC pattern: The View interacts directly with the Model (contrary to the PM pattern). The SC acts only as a mediator, once the connection between View and Model is established, the SC is no longer involved.

The SC has the following responsibilities (leaving aside view entities, as they constitute only a minor part of the data model):

  • Handling the controller logic part
  • Talking to the service

Obviously the SC as less responsibilities than the Presentation Model, resulting in less complexity, and better separation of concern. On the other hand it is also less flexible and thus less applicable in complex cases.

The Relation to MVVM

Matter if fact, this is the way MVVM for Silverlight is usually presented: If you find a more recent description of Silverlight with MVVM (which is curiously not that easy), it is probably similar to my own introduction. Dan Wahlin has recently written about the topic, focusing on SL, and it’s probably the most concise introduction to MVVM with SL I’ve found so far. And again, his code snippets and text descriptions clearly follow the SC pattern. (Curiously his images follow the PM pattern, but since he never names it and takes a rather pragmatic approach anyway, I’ll leave it at that. 😉 )

Notwithstanding the verdict: From a purely formalistic point of view, this is simply wrong! If MVVM is defined as a derivate of the PM pattern (as it was originally introduced), it cannot follow the SC patter at the same time. Both patterns follow contradictory approaches regarding the data model and the resulting ViewModel responsibilities. Actually it is even worse: Since it is not even a responsibility of the SC to define a data model in the first place, the term ViewModel is grossly misleading.

However, given that the Model for SL applications is usually code generated and supports everything that is needed for databinding, the beauty of this approach is its ease of use. At first. (In other words, stay tuned…)

That’s all for now folks,

Excursus: Presentation Model Pattern

Filed under: .NET, Silverlight, Software Architecture — ajdotnet @ 3:24 pm

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,

Create a free website or blog at WordPress.com.