Over the past year I've spent a lot more time working with Silverlight and WPF (XAML) in building applications and samples for demos or for my own internal utilities. While cutting my teeth and climbing the learning curve, I saw lots of references to a pattern called MVVM or model-view model-morel. The idea behind MVVM is to make life easier in creating custom XAML based applications. Over the last few months I've had a few people ask me how I learned it and why I like MVVM. Like other posts, I like having a post on my blog that I can point people to… so here it goes...

What is MVVM?

There are plenty of people, blog posts and articles that describe it, but here's my take:

There are three pieces in MVVM. The Model is the business component, the backbone of your application. I like to start building this as a class library and then create a separate test project that contains unit tests to test the model. Best part is I can create the entire application ignoring the UI and make sure everything works with unit tests.

The next piece is the View. This is the UI… each view is  a different "screen" or component. There's zero logic here.

The last piece is the View Model. The view model is the glue between the other two pieces. It creates instances of the Model and does all interaction on it. It also has public properties. What happens each view's DataContext is bound to an instance of a view model. Then controls within the XAML of the view have their data sources bound to the properties that exposed by the View Model.

Why does MVVM appeal to me?

The two biggest things that appeal to me with this model is (1) there is a 100% complete separation of the UX and logic of my application. That builds into the second reason which is (2) it's super easy to write unit tests against this type of a solution.

When you leverage WPF's (and Silverlight 4's) commanding framework, it enables you to completely remove the whole event-handler method of building a UX. No more OnClick like events… just bind a button to a command and let the command tell the UX if it is allowed or not at a given time. Best part: wiring up the command (logic) to the UX requires ZERO code… it's all done in markup in the XAML!

How I learned MVVM:

First of all, I had to decide I'd just put my head down and force myself to use MVVM in an application. It took me about 3-5 days to fully understand MVVM as I applied it to a project I was working on.

I first watched a few videos from Pixel8, a podcast by Infragistics. There's one video on doing MVVM in WPF and another with Silverlight that helped with the simplest of examples.

Ongoing, StackOverflow does the best job in finding answers, researching and asking questions around MVVM.

How I do MVVM:

So after learning MVVM and building a few apps, like many other people I've got my own process of creating apps that leverage the MVVM pattern. I thought I'd share these with you:

• I prefer to build my model first, including all the unit tests. This way I can make sure my application works and thus, when creating the UI I don't have to focus much on the business logic.
• After the model, I then like to build the view. This allows me to ignore the business logic and focus on just the UX of my app. As I moved through the creation of the different views I can add all the data binding to the controls. Unlike in other technologies, XAML doesn't blow up when the properties I’m binding to aren't present, it just shows up as empty so the view can still work. I can even use the sample data capabilities in Expression Blend from the classes in my model.
• At this point it's time to wire the model together with the view using a view model. There's one view model for each view. His job is to create instances and interact with the models. It also has the properties that I've binding to from the view. Last step: create an instance of the view model in the constructor of the view and assign it to the data context of the view. What's nice about this is that the view model has zero UX in it so it's fully testable too!
• I usually build a few views for each component in my app. Sometimes it is iterative… in other words sometimes every time I build the view I build the associated view model.