.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 – Philosophy and Case Studies - Introduction

There’s been a lot of talk lately about MVVM (Model-View-ViewModel) in the WPF and Silverlight space.  Recently, Ward Bell had an interesting post on the subject where he digs into some of the patterns he is using to support his MVVM triads.  The WPF/Silverlight community is constantly droning MVVM, but almost no one goes beyond stating their use of the pattern or giving an overly general description of it. That’s why I enjoyed Ward’s post.  He’s trying to get into the nitty-gritty of his UI architecture rather than just chanting “I'm using MVVM" and leaving it at that.

I’m pleased that the WPF/SL community is taking UI architecture seriously, but I think we have a long way to go.  We need to dig deeper into the “how” of the MVVM and realize that a solid implementation is more that just creating a model and binding it to a view, with a dash of the Command pattern thrown in for good measure.  In fact, saying you are using MVVM for WPF/Silverlight is sort of like saying you are using MVC for web development.  It more or less states the general design approach you are taking to the UI architecture, but doesn’t say much about how the pattern is implemented or how individual features are represented within the context of that design.  If you’ve been following the blogs on ASP.NET MVC, you’ve probably discovered that there is a lot more to it than just having Models, Views and Controllers.  It is easy to use the MVC pattern very poorly and the same goes for MVVM.

Speaking of context…

When I first read the GoF book, I was baffled by its insistence that patterns were not tied to implementation.   Sure, I understood that the Iterator pattern would be implemented differently in C++ than in C#, but I didn’t understand that other context-specific factors had a massive affect on the details of its implementation.  This “phenomena” manifests itself in greater degrees with respect to how high-level the pattern is.  A high-level pattern like MVC is a fine example of this.  Consider how the implementations would differ between a WinForms and an ASP.NET implementation of this pattern.  They would not resemble each other much at all.  The WinForms version would likely look a lot like an Observer or Mediator while the ASP.NET version would be very similar to a Strategy.  In fact the WinForms version would look so different, you might not even call it MVC anymore, though you started out with an MVC mindset.  You could force the WinForms and ASP.NET implementations to look alike, but you would be creating a leaky abstraction by forcing an artificial context for your design to live in.

In the next couple of posts I am hoping to examine MVVM within the context of WPF/SL.  What does the base form of it look like?  What do more complex forms look like?  Why is this pattern a good fit for WPF/SL?  How does this pattern relate to MVP and MVC?

MVVM – A Simplistic View

If we take MVVM as a high level pattern, like MVC, then it becomes our general approach to architecting user interfaces.  It means that we will have components in three of the following broad roles:

Models – These are the business-oriented components that are intended to be displayed or manipulated by the application.  They might be traditional business objects rehydrated from the DB, messages from a web service or anything else that has business meaning independent of presentation.

Views – WPF/Silverlight is a view framework and is thus intended to provided these components.  Their role is to display something on the screen.  Nothing more, nothing less.

View Models – This is a special type of model, intended to be an abstraction of the UI.  You can think of it as a logical representation of the UI.  It is “connected” to the view at runtime through databinding.

My guess is that you probably feel pretty comfortable with the idea of a Model or a View.  You can picture them in your mind.  But when it comes to View Models, things get foggy.  It means that we need to have a lot more discussion around what our View Models look like.  But, we cannot just discuss them abstractly.  We must look at specific scenarios and see how ordinary design patterns interplay to create a meaningful model of the UI.  In a few words, here’s my general philosophy and what I hope will become clear as we proceed:

The same OOD techniques you use to build your backend systems are used to construct your View Models.

To that end, I am hoping to put together several posts on the subject.  I am planning to contact several of my previous clients with the intention of gaining permission to discuss small portions of their applications; or to discuss them at a very high level.  I want to show specific problems and demonstrate how we used common design patterns to build a rich View Model.  It is my hope that this will begin a richer discussion on the topic within our community.

Posted 07-07-2009 10:49 PM by Rob Eisenberg



Steve wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-07-2009 11:08 PM

I look forward to this series - thanks Rob

Ward Bell wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-07-2009 11:25 PM

Beginning with great promise. Looking forward to the series.

Absolutely agree that these higher level patterns resist context-free implementations. You have to see them in the context of concrete business problems and the chosen technology vehicles  ... as you say.

Some patterns only make sense for certain technologies. ViewModel is reasonable for WPF/SL because of its strong databinding; it's too hard to do in WinForms and I can't imagine how it would work in ASP Web Forms.

I will be interested also to see how you talk about some of the difficult choices for a VM's responsibilities: what should it know about the model, how will it collaborate with objects outside the triad, does the VM know the V, can a VM support more than one V (or a V be supported by different VMs). Should be entertaining and informative!

Christopher Bennage wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-08-2009 12:48 AM

It's Opinionated ViewModel.

Laurent Bugnion wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-08-2009 8:14 AM

Looking forward to next posts. Yes MVVM is rich and has many "flavors". And yes, we need to educate people about it and to make it easier to understand and create MVVM applications.

Not wanting to self-promote (well just a little) but I recently published a MVVM toolkit which makes it much easier to start with MVVM. In the next weeks, I want to publish samples and get started information based on the toolkit. The URL is




Vadim Kantorov wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-08-2009 11:01 AM

Very promising!

Keep on going!

Jason F wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-08-2009 8:39 PM

Ha, stop reading my mind and answering the questions I've yet to ask.

Maybe the name of View Model was a poor choice when the other two parts are View and Model. Oh Microsoft, at it again are we?

Jeremy Gray wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-08-2009 11:56 PM

"things" will most certainly "get foggy" around View Models when you've defined them all but backwards. View models are not "an abstraction of the UI", they are a _UI-oriented_ abstraction of _the_model_.

You aren't the first to make this mistake, and certainly won't be the last, but since this is the cause of much of the "fog" that you reference, perhaps in a follow-up post you can dig into why you've flipped the definition around?

PS - I had to copy/paste into Firefox just now as your captcha is broken in Chrome.

Rob Eisenberg wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-09-2009 7:50 AM


I agree with you 100%.  I think my wording is a bit confusing.  Part of the problem with describing ViewModel stems from the fact that it functions as an adapter.  That is, it adapts the Domain Model to the View.  So, in that sense, it abstracts the Domain Model away from the View so that the View only has to understand the ViewModel, and knows nothing about the DomainModel (though this is not the case in every application).  However, if you look at a ViewModel from the outside (the public API of the class(es)) then the ViewModel itself appears to be an abstract form of the View.  In other words, the properties on it correspond to information displayed in the UI and its Actions/Commands correspond to things the user can directly invoke.  There's more to it than this, becuase some times, the ViewModel actually does abstract the View away from the model...   I'll try and put together a post to discuss this a bit more.

jbe wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-10-2009 9:33 AM

Hi Rob,

I absolutely agree with you that it is not enough to have a Model, a View and a ViewModel in an application. There is more to get a clean UI architecture.

We are using MVC and extend this architectural style with the MVVM pattern. How this looks like is shown here:

WPF Application Framework (WAF)


pcdinh wrote re: MVVM – Philosophy and Case Studies - Introduction
on 07-10-2009 1:30 PM

Looks like that you have the same idea with me. I think that the architecture that you mentioned is implemented in my own framework Spica:  http://code.google.com/p/spica I called it MVC-Pull which some View-oriented component s are results of Models and Views connection

9eFish wrote MVVM – Philosophy and Case Studies - Introduction - .NET & Funky Fresh - Devlicio.us
on 07-12-2009 10:27 PM

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

Ward Bell wrote re: MVVM – Philosophy and Case Studies - Introduction
on 08-01-2009 5:57 PM

@Jeremy I disagree. The ViewModel exists to server the View. It is an abstraction of the View and NOT of the domain model. The VM's job is to provide state and behavior for the View.

Let me prove it. You define a Query-By-Example view whose sole purpose is to gather search criteria and, upon press of search button, package the entered criteria and send to a search service. It need have no idea where the search results will appear.

The VM in this case is bound to the visual controls through which the user specifies values. It has logic for the packaging. But nothing about it or what it does is in or about the domain model. Search criteria are not part of your domain model. They aren't (usually) persisted. The aren't part of your "ubiquitous language."

Another example, the VM behind a login. It's job is to assemble credentials, pass to a login service, and respond appropriately ... that is instruct the View ... based on what the service reports back. You won't find anything here that involves the domain model. You can claim that it will get the user and roles and these figure in the domain. But your app may simply be satisfied with logging in and having a user name to display.

It is true that the VM is usually mediating between a View and the domain model. But it isn't necessary or fruitful to make this essential to its definition.

Nope ... I like Rob's original formulation (tsk, tsk, Rob, for giving ground so easily :-)  ). The ViewModel is most definitely an abstraction of the view. The fog really descends when you put the Domain Model at the center of the ViewModel.

Rob Eisenberg wrote re: MVVM – Philosophy and Case Studies - Introduction
on 08-02-2009 12:12 AM

@Ward @Jeremy

I find myself agreeing with each of you.  I'm trying to put my thoughts on this together.  Hopefully it will result in a post that add value...

.NET & Funky Fresh wrote MVVM Study Part 2 – “View of the Model” or “Model of the View” ?
on 08-02-2009 5:40 PM

As a follow-up to my last post on MVVM , I want to further investigate the ViewModel as a concept. In

Glenn Block wrote The spirit of MVVM (ViewModel), it’s not a code counting exercise.
on 08-03-2009 1:15 AM

<Warning>Long post follows</Warning> Lately there is a lot of momentum and interesting conversation

SteelePrice.Net wrote Glenn Block on MVVM
on 08-15-2009 1:21 AM
Samoys wrote re: MVVM – Philosophy and Case Studies - Introduction
on 10-03-2009 9:32 AM

lot about you

Roberto wrote re: MVVM – Philosophy and Case Studies - Introduction
on 10-04-2009 4:26 AM

cool blog

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)