Papa's Perspective

Fundamental MVVM

Understanding Model-View-ViewModel is the first step in using it.

Want to make Model-View-ViewModel (MVVM) simple? I know I do. First, I want to explain why I think MVVM appears complicated to many folks, when I think it's quite the opposite.  In fact, I think MVVM can prove more valuable that not using MVVM in almost any situation. But for that to happen, first we have to understand what MVVM is and is not.

While very popular, the MVVM pattern is often misunderstood.  Sometimes people lump commanding, behaviors, messaging, service locators and other technology features into MVVM. While these are powerful and great features, they're not MVVM; they're helpers you can choose to use with MVVM.

Am I nitpicking? I don't think so. Consider it this way: Can you use MVVM without these features? Absolutely.

Another confusion point is with the frameworks surrounding MVVM. Some I'm very familiar with include PRISM, MVVM Light Toolkit, Caliburn Micro and Cinch. While these frameworks and toolkits are widely used and can prove very valuable, they're not essential for MVVM.  Once you clear aside what is not in fact part of MVVM, the rest becomes much clearer.

Once you weed out all the helpers, the essential aspects of MVVM remain: The Model, the View and the ViewModel (what I sometimes call the triad). OK, so that may sound a little anticlimactic, but I can't help if it's true.  MVVM is defined by the separation of the Model from the View from the ViewModel. This separation pattern clearly delineates the responsibilities of each of the triad members.

The Model contains the data points that the application requires. Sometimes this comes from a WCF service, a RESTful service, or data aggregated from many places. Where the data comes from is irrelevant. What's important is that the data is pulled into the client and stored in the Model. For example, if building a Twitter client, you may have a set of Model classes for User, Tweet, and Tweets. These classes (sometimes known as domain objects) may be collection classes or single entity classes. The main responsibility of a Model is to describe the data required by the client. Thus a Model is born.

[Click on image for larger view.]
Figure 1. Flow in Model-View-ViewModel.

The View is the friendly presentation of information to the user. A View may include themes, styles, controls, bindings, events, and other interactions on the screen. The View's responsibility is to keep all presentation in a single place, unencumbered by logic and other heavier code. Often the View will have controls that will map to one or more Model's data points. (In Silverlight, Windows Phone and WPF these controls often map declaratively through data binding XAML markup.)

The ViewModel is the glue between the View and the Model(s). The ViewModel is also known as the "View's Model" because it exposes public properties intended for the View. Often the ViewModel aggregates one or more Models and exposes them to the View as public properties.

The ViewModel is intended for the View, so aggregating the Models in the ViewModel allows the same Models to be reused by many ViewModels (and thus by many Views). Abstraction and aggregation of Models is just one aspect of a ViewModel, however.

Sometimes a View may require a data point not in any Model. This might be a UI-specific property like IsBusy for a ProgressBar control, or some calculated property using logic. These View-specific data points can be created in the ViewModel as public properties without muddying the Models. This is abstraction and separation at its core.

But that's not all a ViewModel does. As I mentioned, a ViewModel is the glue between the View and the Model. Because XAML has a great binding story, MVVM really shines. The View's DataContext is set to an instance of a ViewModel class. This gives the View access to all the public properties in the ViewModel.

There are other variants and extensions of what the members of the MVVM triad can do. For example, does the ViewModel go get the data and load the Model(s), or do the Model(s) know how to load themselves? (I highly recommend and prefer the former.)

Whatever your choice, it's still MVVM. You can also debate methods to bind the View to the ViewModel. Whether you do it in XAML, the codebehind, the ViewModel or in a third-party class (what I call the marriage between View and ViewModel), its still MVVM. My point here is that you and your developer colleagues may deviate and differ on how to implement MVVM, but at its core MVVM is just the separation of the MVVM members. In my next blog entry, I'll provide some brief code examples to illustrate this separation.

About the Author

John Papa is a Microsoft Regional Director and former Microsoft technical evangelist. Author of 100-plus articles and 10 books, he specializes in professional application development with Windows, HTML5, JavaScript, CSS, Silverlight, Windows Presentation Foundation, C#, .NET and SQL Server. Check out his online training with Pluralsight; find him at and on Twitter at

comments powered by Disqus

Reader Comments:

Wed, Aug 24, 2011 Erno

It is possible to use the System.Windows.Interactivity without installing Blend. All you need is the Blend SDK (which is free) Unfortunately there is hardly any documentation on how to use the behaviors in Xaml as these were meant to be used in the designer. But it can be done.

Sun, Aug 21, 2011 David Seruyange Sioux Falls, SD

@Oskar - I understand your issue with event support. Fortunately you do not have to install Expression Blend in order to have this support. My favored approach is to use the MVVM Light Toolkit which has something called "EventToCommand" which allows you to wire events to commands that you can bind in the UI with a behavior. You can follow the tutorial here: Skip to the section called "In XAML" if you want to do it directly in Visual Studio, rather than Expression Blend. Some of the things I've found more advantageous with EventToCommand: 1. Loading Events (User control loading, etc...) 2. ComboBox and other SelectionChanged type controls *especially* where an event argument passes something useful to the event handler. 3. TextBox TextChanged - to provide databinding support that goes beyond just a lost focus on the textbox. There are others, but I'll leave it at those 3. You may already gather from my response that I like MVVM Light Toolkit a lot. We've used it successfully on a few projects where I work (Daktronics, Inc.). We are transitioning to use a little bit more Prism but I think MVVM Light is the best way to get off the ground when learning MVVM though I don't have experience with some of the other toolkits.

Fri, Aug 19, 2011 Kenny Woo Viet Nam

Dear Oskar - I think you can resolve your issue by using System.Windows.Interactivity(you must install Expression Blend) then implement this to your control which you want handle event i.e: You can call all event in EventName. Hope this help for you...

Thu, Aug 18, 2011 John Papa

Oskar - Thanks for the comment. I'll be sure to bring it up in a future post. What types of events are you referring to? Or do you just mean you want to be able to bind to any event? There are a few ways to handle that with MVVM. I'll touch on them ... good post idea :)

Thu, Aug 18, 2011 Oskar

What about events. In my application i need many events and most controls have only one command for the most used event. Everyone speaks about MVVM but in the most examples no one tells me how to handle events. I would appreciate if you can broach this in you next blog entry.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.