Silverlight and MVVM

All of Affirma Consulting’s Silverlight projects use the MVVM (Model-View-ViewModel) pattern. This design pattern is modular, testable, and takes advantage of Silverlight’s powerful data-binding capabilities.

You can find many, many more with a quick Google search and you’ll quickly learn that arrayed around the central MVVM pattern, people tend to use things like ServiceLocator patterns, variations on Observer or Signals And Slots to perform messaging between ViewModels, and that really no one completely agrees on what MVVM is. That’s one thing you quickly discover. There 8 dozen existing MVVM frameworks out there. They each wire up the references in a different way. And they each contain a different sampling of satellite features.

For example, what is a ViewModel? Is it a view into the Model? Maybe. It certainly wraps the model data in a form that is useful for the view. But more than that, it’s a model of the view. The ViewModel maintains state for the View. Anything in the View that can change should be bound to a property on the ViewModel. But now the ViewModel is performing two jobs, which is a violation of singularity of purpose. So we could split it in two and have a model wrapper and a view state machine. There’s a reason no one does this. It’s just too much make-work for the payoff. When done well, our ViewModels tend to be pretty simple anyway. Why create roadblocks between the view state and the model state?

This is just the first of many postings we’ll be making on MVVM. Check back frequently for discussions of the intricacies.