When I was at BIG, I created what I called the Extended MVP pattern. I built a framework that was used on multiple projects for managing the presentation layer as well as validation. I’m still very happy with what I created, and my teams at BIG are still pleased with those applications as well. In fact, I just learned that they were looking into using the pattern within a Silverlight project they’re doing a proof of concept for. I mentioned the ViewModel pattern to them, suggesting they use it instead of using the MVP approach. When asked for more information, I decided I should just write a blog post.
I hadn’t heard of the ViewModel pattern until I joined Microsoft. But I hear about it all the time now, both inside and outside Microsoft. Yet I don’t know of any authority on it like we have Martin Fowler for MVP. The closest thing we have is a blog post from John Gossman where he introduced the pattern.
John does a great job of explaining how data binding can be used against a ViewModel. The general idea is that your View is provided a Data Context that it can bind to. The ViewModel surfaces all data that your View needs to display, and the ViewModel also has properties for all data that your View needs to collect. It’s similar to MVP, except the ViewModel is completely ignorant of the View and instead of the Presenter pushing data down to the View, the View pulls data down from the ViewModel and can also push data into the ViewModel.
The first sentence in John’s article instills a bit of confusion I think. This sentiment is repeated a couple of times throughout the article too.
Model/View/ViewModel is a variation of Model/View/Controller (MVC) that is tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer.
Saying that the ViewModel (for short) pattern is a variation of Model/View/Controller implies to me that it can be used instead of MVC. In fact, the ViewModel pattern can be used in conjunction with MVC if you’d like. I have seen this pattern and talked to developers that are using this approach. I refer to this as the MVC+VM pattern or Model-View-Controller with ViewModel. Whether or not you have a ViewModel is orthogonal to whether or not you have a controller. I’ve talked to John about this and he concurred that the patterns are really mutually exclusive.
As far as the definition of a ViewModel, John’s article sums things up really well with the following clause:
The ViewModel is responsible for these tasks. The term means "Model of a View", and can be thought of as abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model.
Neither WPF nor Silverlight has first-class support for the ViewModel pattern. But they don’t necessarily need to have anything to explicitly support the pattern, as it’s just that—a pattern. Furthermore, there are countless ways to implement the ViewModel pattern, but the principle stays the same: provide an abstraction layer that the View can work against. This gives you a facade between your actual Model/Services and your View, which is ultimately what we want. The framework enables this even though you won’t find any namespaces or classes specifically targeting the ViewModel pattern.
Nikhil Kothari has written about the ViewModel pattern in Silverlight. He also goes a few steps further and he has created a Silverlight.FX library that has attached behaviors to simplify the declarative use of ViewModels. I really like how Nikhil describes the ViewModel too.
This can also be read as "The View's Model" which is a bit more representative of its function. This sits in between the View and the Model and surfaces data in a form that is more suited for viewing or editing. It also defines operations that can be invoked to perform some work, often times resulting in changes to the data that the View is bound to. While it doesn't depend on the View, it is logically associated with one in a one-to-one manner. This might be partially code-gen'd as well, but for the most part this is authored in code.
The reason why I like ViewModel as much as I do when working with Silverlight and WPF is because of XAML’s data binding support. Being able to declaratively provide a ViewModel to the View and then just use declarative binding to pull and push data from/to the ViewModel is awesome. It keeps the View very slim and allows the ViewModel to be completely ignorant of the View’s usage of its data.
Something to watch out for when creating a ViewModel is that you shouldn’t let your View implementation leak into the ViewModel. For instance, if you have a portion of a screen that is only visible under certain conditions, you’ll ultimately need to set a control’s Visibility property—this property accepts a Visibility enum of either Visible or Collapsed. In this case, you might feel inclined to expose a Visibility property on your ViewModel, but you should rather expose a boolean property and use a BindingConverter to convert the boolean value to the Visibility enum. Letting the ViewModel expose Visibility is a slippery slope toward having View implementation embedded in your ViewModel, which is a violation of the pattern.
Once you start using the ViewModel pattern, you’ll find that it’s very addictive. You have to get into a new mindset, much as you do with MVC; but once you grok it, you’ll never turn back. You’ll soon find yourself wondering what kind of code logic you’d ever put in your code-behind again.
Feel free to ping me with questions about the ViewModel pattern.