I’m a huge soccer fan, so every four years, I get swept up by World Cup fever. This year has been particularly unusual in that perennial underdog United States (to my delight) won its group while both finalists from 2006 (Italy and France) didn’t even make it to the knockout round. But, as the famous American sportscaster Chris Berman so eloquently puts it, “That's why they play the games.”
The same level of unpredictability happens in software development every day, which is a big reason why my team is moving to the Model-View-ViewModel (MVVM) pattern for our next project. MVVM creates a clear separation between the user interface (the View) and the application logic (the Model), which enables just about the entire application to be unit tested. We can “replay the game” over and over, just in case something unexpected happens as a result of a seemingly unrelated change. MVVM also allows for the wholesale swap-out of the View from Windows Presentation Foundation (WPF) to, say, Silverlight, with only minimal retooling for things like page navigation (for which we are using a simple Mediator pattern).
I was in for a treat when I began looking for the implementation of the MVVM pattern that best suited the needs and preferences of our team. There are quite literally dozens of options to choose from, including rolling our own MVVM framework. Since we are relatively new to the pattern, we decided that it would be best to leverage an existing framework that already had infrastructure in place to tackle many of the challenges that such a decoupled pattern presents.
We reviewed several frameworks including Microsoft’s Prism and Caliburn. Two requirements that we felt strongly about were that the framework should emphasize configuration over convention and that it should have as few moving parts as possible. Our team has a couple of designers on board, so compatibility with Expression Blend (or “blendability”) was important as well.
I think that we found a near perfect match in MVVM Light. (You can check it out at http://mvvmlight.codeplex.com/.) I say “near perfect” because we had to convert the ViewModel engine to support a factory model whereby multiple instances of the same ViewModel could exist simultaneously (versus using Statics). We also had to implement the aforementioned Mediator pattern to handle page navigation, but the awesome messaging support in MVVM Light made that a snap.
I’m excited to begin my first large-scale project that leverages the MVVM pattern. Our last project used the Model-View-Presenter (MVP) pattern, so I am still getting used to not having the convenience of a reference to my View near my business logic. In fact, we have opted to put our Views and ViewModels in separate Visual Studio projects so our Views can reference our ViewModels, but our ViewModels will be prevented (due to circular references) from referencing our Views. This will prevent us from the temptation to break ranks from the pattern. I do look forward to the benefits that the more loosely coupled MVVM pattern brings with it, and I think that it will be worth the extra effort.
