MVVM needs (re)definition

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…

Verdict

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,
AJ.NET

Advertisement