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.
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.
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:
- a method called
UserControlclass representing a widget or collection of widgets on the screen
- data binding with interfaces named
- data templates
- commands (which are really MVP interceptors)
DataContextproperty on the view
- run-time type information
- data validation through interfaces named
- a class called
ObservableCollection<T>which means you need a language that supports type parameters
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,
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.
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]
- 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
- 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.
In the near future, I should complete a formal pattern definition for the Generalized MVVM. I’ll post that when I complete it.