Many design patterns have evolved in time over the need to support building “well designed” applications. From Model-View-Controller to Model-View-Presenter (or passive presenter), all the way to the MVVM – “Model-View-View Model” pattern. I am not going to get into a deep philosophical discussion of the differences between them, and what is the “best practice” approach to MVVM. This is one of these topics where 10 developers will give you 20 different opinions. The agreed upon guidelines are that the model should represent the logic of the application, and that each view should have its own specialized model called “view model”. The view keeps a reference to the view model (but not the other way around) which exposes items like commands, and observable entities that the view binds to. So as you see, the concept of “binding to an observable view model” is at the core of this design pattern. So this atomic topic is at the center of this post.

What is MVVM good for?

The MVVM design is a tool in building well designed application. Well designed applications should be easy to develop, test, maintain and evolve.

Specifically, in the case of XAML based applications (which is a common name for WPF, Silverlight, and lately WinRT applications) the design should allow you to:

  1. Testability – Easily produce and maintain isolated automatic unit tests to every piece of code that has logic. (in MVVM the focus is mostly on the Model classes and the View Models, but even parts of the views can be automatically tested).
  2. Blendability – Design your XAML views using Expression Blend or Visual Studio XAML designers without having to execute the application to see results. Specifically, you would like to bind your views to design time data and see what your view would look like in various states (scenarios) of its view model.
  3. Refactorability – Refactor your code using Visual Studio 2010 refactoring tools. (Ok, I admit, that last term is made up by me, but I still think its valid)

All of these goals typically revolve around separation of concerns and encapsulation of responsibilities. The idea is that the units of code such as view models and the model services should be encapsulated in a way that allows them to be constructed in isolation. For a view model to be tested, it should be developed in a way that allows it to be constructed with the least amount of dependencies on other units. Resources should be provided to it using some sort of Dependency Injection, so you should be able to instantiate it, call a method or a sequence of methods and then test the results. For it to be designable the view model should has to be constructed inside the “design time” container so it needs to produce reasonable results without relying on services to perform well, or by using an injection of a service design time substitute. So basically, when developing a view model or service, the developer needs to think about how the view model will be used not just in run time but also in “test time” and in “design time” and make sure it is “standalone” enough to function well in all of these scenarios.

MVVM Frameworks

There are several frameworks that provide libraries of helper classes, containers, and patterns that allow the user to get started easily (relatively) with MVVM. Microsoft has released PRISM – a set of tools that allows you to create application as a group of independent modules. Laurent Bugnion has released a toolkit called “MVVM light” which is a light weight framework aimed at accelerating the creation and development of MVVM applications by helping you to separate your View model model and create testable applications. Simple MVVM Toolkit, Caliburn, MVVM Foundation and Silverlight FX are other frameworks which are relatively widely known. A short google search would proably produce other frameworks.

While I would not specifically encourage or discourage the use of any specific framework, I would always recommend to learn and adopt the ideas behind them. Each framework provides creative ideas and best practices, and my experience so far is that each of them is ideal for different scenarios. In fact, I would also recommend to consider the possibility of developing your own framework based on the specific requirements of the project you are developing. I am not always against reinventing the wheel, just as long as you make sure to study all the wheels that were already made and decide which of their features you need and which you don’t.

In the following posts, I will dig into some of the requirements that an MVVM developer should consider and suggest several ways to tackle them.