There are several major architectural approaches used in building user interfaces. MVC, MVP and MVVM seam to be the most popular of the bunch. From among them, MVVM has risen to the top of the stack for WPF and Silverlight developers. Even ignoring the question “Why use separated presentation at all?”* and asking “Why MVVM?” yields an answer with many facets. In this post I’m mostly interested in in how MVVM exhibits Conceptual Integrity with WPF/SL. I believe that it is for this reason that most developers are using MVVM over another pattern. For a very good discussion of some other aspects, have a read of Glenn’s recent post.
Here’s how the book Beautiful Architecture describes Conceptual Integrity:
“Conceptual integrity comes from consistency in things like decomposition criteria, application of design patterns, and data formats. This allows a developer to apply experience gained working in one part of the system to developing and maintaining other parts of the system. The same rules apply throughout the system.”
Even if you haven’t pondered the concept of Conceptual Integrity explicitly, you have more than likely felt when it was not present in a given architecture. I think this term describes well the sentiment held by developers switching from WebForms to ASP.NET MVC (or Rails for that matter). WebForms does not exhibit Conceptual Integrity in the context of the Web, while MVC does.
Below are three WPF/SL concepts with which I think the MVVM pattern resonates well. That is to say, the MVVM pattern came to the forefront of UI design patterns for WPF/SL because it is consistent with the following core concepts of the platform:
WPF and Silverlight have richer databinding support than has previously been available on the Windows platform (perhaps any platform). If you talk to an experienced WPF developer, I would be surprised if he/she didn’t list this as one of the most, if not the most important aspect of the framework. It is what enables a developer to create a fairly pure model (the ViewModel) and then stick the View on top of it. Databinding is the “adhesive” that allows us to get rid of the manual push/pull synchronization code that is required in an MVP design. Indeed, the original PresentationModel pattern, arose in correlation with earlier databinding mechanisms.** So, it’s not surprising that WPF’s super-charged databinding would bring this pattern to the forefront and give it a new name: ViewModel. In short, databinding provides a consistent mechanism through which a developer can describe how a View and ViewModel will interact.
If you look at the WPF/SL control architecture, you’ll notice something quite interesting: A Control’s behavior and its View are separated. The platform splits controls into two parts, the Control class (ViewModel) and the ControlTemplate (View). Yes, one reason why MVVM makes sense is because the platform itself is architected in that way. Recalling the previous point: How do you describe the interaction between the Control Class and the ControlTemplate? TemplateBinding. Of coarse, you could venture to build your own MVVM architecture by creating your VMs as descendants of Control and then defining Views as ControlTemplates (please don’t do this). But, there is a better way. DataTemplates extend the same concept by allowing Views over any type of object. And of coarse, Databinding is used to glue the object to the template. So, you can imagine how Gossman’s original description of MVVM was very intuitive for him even if he hadn’t read Fowler’s description of PresentationModel. It was a logical extension of the underlying platform.
Fowler has this to say:
“In the case of composition a Presentation Model may contain one or many child Presentation Model instances…”
And Gossman says*** that the MVVM pattern has a
“hierarchical nature … as we practice it”
WPF is a composition-based framework at its core. Consider the RichTextBox control. It’s behavior is in the control class. Now, look at its ControlTemplate. It typically contains a ScrollViewer. That’s a completely different control with its own behavior and view. Here’s where it gets really interesting. When you create a RichTextBox, at runtime, WPF is composing the behavior of multiple controls and in parallel composing the views of those controls (because the ScrollViewer is composed of ScrollBars…which have their own behavior/view). You can, of coarse, accomplish the same thing with DataTemplates and ViewModels. In many ways, I think this is the real ultimate power of WPF/SL. I’ve found this to be an extremely important concept. When tackling a complex screen, decompose it into a series of smaller models. WPF’s compositional nature encourages this, as it can easily put the pieces together for you.
I’ve listed a very small number of concepts that I believe are central to development with WPF/SL. It is out of these same concepts that MVVM naturally emerges. I’m sure many WPF devs started building things this way without reading either Gossman or Fowler. It makes sense for the platform. It exhibits Conceptual Integrity.
* I’m ignoring it because it has been answered very thoroughly many times before and I’m assuming you have already decided this is a good idea.
** Note that Fowler hopes .NET will bring improved databinding to the scene.
*** Actually, Gossman’s second explanation of MVVM is the better of the two. I’m afraid far less people have read this than the original.
09-01-2009 4:39 PM