.NET & Funky Fresh



  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
MVVM Study Part 3 – Why?

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.

Final Thoughts

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.

Posted 09-01-2009 4:39 PM by Rob Eisenberg



9eFish wrote MVVM Study Part 3 – Why? - .NET & Funky Fresh - Devlicio.us
on 09-02-2009 1:36 AM

9efish.感谢你的文章 - Trackback from 9eFish

Morten Jacobsen wrote re: MVVM Study Part 3 – Why?
on 09-02-2009 3:47 AM

An excellent article. I read quite a few, and this was the first I could say that I understand completely. The notion that WPF/SL are built on the MVVM models is crucial for me.

Ryan Riley wrote re: MVVM Study Part 3 – Why?
on 09-02-2009 10:24 AM

Terrific article, and I agree with everything you said. I really appreciate you highlighting the correlation of Control/ControlTemplate to ViewModel/DataTemplate. That has been tugging at the back of my brain, but I couldn't articulate it as such.

I am curious, however, why everyone has such a problem with Controls (or even DependencyObjects) as a base for ViewModels. I'm not necessarily for it except to maintain a stricter POCO style, but are there other reasons?

Also, if you do a follow up, you might emphasize the helpfulness of the DataTemplateSelector (WPF only at this point but other options exist for SL). We're using that in several places for view composition instead of tons of DataTriggers.

Luke Foust wrote re: MVVM Study Part 3 – Why?
on 09-02-2009 2:58 PM

By the way, one of the ads you are displaying under "sponsors" (the one in the lower right) causes an authentication popup every time I visit your blog. Here is the url that seems to be causing it: http/.../ANTS_125x125_M2.gif

Rob Eisenberg wrote re: MVVM Study Part 3 – Why?
on 09-02-2009 11:09 PM


Thanks for the heads-up.  We are looking into that.


There are a couple of reasons for not doing this.  You've mentioned POCO, which I try to attain whenever possible.  Additionally, DependencyObject/Control are based on DispatcherObject which is a strange dependency to have in unit tests sometimes and having to implement DPs for everything in your VM would be tedious.  In general there is weight in DO/Control that doesn't really buy you anything.  ViewModel/DataTemplate or even a custom mechanism will get you everything you need pretty easily.  Also, realize that a ViewModel is not really substitutable for a control/do, so using it as a base class is architecturally confusing.  In general, inheriting from a base class is a very strong form of coupling.  Because .NET only has single inheritance, you have to think very carefully about when you choose to inherit.  You don't want to cut off your opportunities to compose, which I believe is extremely important in UI architecture.  I'm sure there are other reasons.  These are the ones that are coming to me now.  

Also, I agree that DataTemplateSelector is an important tool.  More recently, for Caliburn, I implemented my own mechanism which replaces template selectors and replaces data templates with standard user controls.  It also adds some other nice features.  It uses an attached property called View.Model which access several pluggable service to do fun things.  If you are interested, you can read the docs on IViewStrategy: caliburn.codeplex.com/.../View.aspx   and IBinder: caliburn.codeplex.com/.../View.aspx

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)