Wednesday, June 5th 2013, 12:00:00 am

For a long time, Model-View-Controller, Model-View-Presenter, and (with far slimmer adoption) associated patterns represented the accepted patterns for the objects that participated in organizing the responsibilities found in a graphical user interface. But, back in November 2010, the Microsoft® patterns and practices team published the Model-View-ViewModel (MVVM) Pattern that takes advantage of their WPF and Silverlight user interface toolkits. Now, we have MVVM toolkits in lots of different languages and rendering targets. This post discusses the pattern, its requirements, and its awesomeness.

A quick aside about software design patterns

I’m going to piss some people off in this section. I’ll do that because of the importance that I apply to the common terms used in the software programming. I get accused of purist views because of the importance that I hold for terms in software programming. And, that accusation sometimes has frustration behind it. And, frustration leads to pissiness.

Spoken language has context and, in the absence of a complete context, ambiguities. Software design patterns help us avoid the pitfalls of ambiguous communication with one another. When I tell you that I used the Flyweight Pattern in a part of the software, then you know that a clear definition of the Flyweight Pattern should exist somewhere and that definition comprises our common understanding of the Flyweight Pattern.

If three other people came along and published well-received software programming books that each contained a definition of a “Flyweight Pattern” that did not exactly align with the Gang of Four’s Flyweight Pattern, the term has become useless for our communication. We’ve lost something precious: clarity.

So, with that said, we have a problem.

The problem with MVVM, the pattern

If you head over to Implementing the MVVM Pattern at MSDN, you’ll see Microsoft’s write-up of the MVVM pattern. The first meaningful sentence from that page, the one that starts the discussion of the class responsibilites, reads

The MVVM pattern is a close variant of the Presentation Model [pm] pattern, optimized to leverage some of the core capabilities of WPF and Silverlight, such as data binding, data templates, commands, and behaviors.

According to this definition, the MVVM pattern relies on “core capabilities” such as “data binding, data templates, commands, and behaviors.” If you don’t have those, then you don’t have MVVM. Actually, if you don’t have any of the following things, then you do not have MVVM, as described by the Microsoft patterns and practices team:

Now, don’t get all fussy with me and demand that patterns are generic and transcend languages and blah blah blah. The patterns that we know intimately, like Singleton and Factory still have expectations, namely, an object-oriented language. Patterns like Strategy, for example, would have no place in functional languages because functional languages treat functions as first-order concepts, they usually have closure, and the idea of a strategy comes directly from the language design!

The MVVM story should just end there. We could just say that we’re done, that the applicability of the MVVM pattern outside the context of Windows Presentation Foundation and Silverlight just doesn’t exist.

That was an easy blog post.

This is not an easy blog post

And programmers saw the MVVM pattern, and behold, it was very good. They wanted to use it outside the Microsoft frameworks because they didn’t have WPF or Silverlight in their applications. They wrote Web pages or Java apps or Brainf*ck programs that could benefit from the MVVM organization of their source code and GUI logic. So, they said, I’ll build an MVVM framework for myself!

Yeah, to do that, they’d need to reproduce, at a minimum, that list of specific expectations from above. Otherwise, we just build something similar. If we come up with something similar to an existing pattern, we should give it another name to skirt the ambiguities of diluted terms.

We, the software development community (or some guy really good at giving names to things), should have generalized Microsoft’s MVVM pattern to strip out the Microsoft-specific cruft. We could publish that better definition with a name like the “Generalized Model-View-ViewModel Pattern” or “Monkey Tacos! Pattern”. If we wanted to keep the palindromic nature of the acronym for more cool points, we could have called it the “Generous Model-View-ViewModel Generalized Pattern”, GMVVMG. But, we didn’t. And, now, we have to work our way backward through the multiple so-called MVVM patterns, extract the commonality, and see if anything of value comes out or if the pattern name has become corrupt through coöpted use. [rest]

Searching for meaning

Head over to Wikipedia’s article on Model View ViewModel and you’ll see four sections on so-called “MVVM frameworks”.

Microsoft .NET Open source MVVM frameworks
Different implementations of the Microsoft WPF- or Silverlight-based pattern described in the originating article. Nothing new there.
Free MVVM frameworks
Here we see some JavaScript or JavaScript+WPF+Silverlight+ASP.NET implementations. These implementations bring us closer to a generalized pattern.
Commercial MVVM frameworks
One WPF+Silverlight framework that we can ignore for the sake of this discussion. Then, an MVVM framework for Unity 3D. Now, there's something different. This should add to our understanding of the GMVVM.
Java MVVM frameworks
Two toolkits for Web-based applications written in Java. We've already got that covered.

So, from the list, we have three essential implementations of GMVVM: the original WPF/Silverlight case, JavaScript implementations, and one for the C/C++ rendering engine for Unity3D. At your leisure, go review these implementations.

In the near future, I should complete a formal pattern definition for the Generalized MVVM. I’ll post that when I complete it.

Footnotes

[moom]: Implementing the MVVM Pattern first mentioned MVVM. ^

[pm]: Presentation Model by Martin Fowler (ALL HAIL MARTIN FOWLER!) ^

[rest]: Like the term ReST became diluted through inexact use ^