If you’ve made a decision to start using the Model-View-ViewModel pattern (abbreviated as MVVM) for Silverlight development, you’re faced with a rather steep learning curve and a scarcity of of accepted standards and best practices.  I’ve read no less than three Silverlight books. All of them have a chapter on MVVM, in which the pattern is explained and some fairly basic examples are provided.  But when it comes to taking on some controversial issues, such as how to display modal dialogs, they tend to sidestep the issue and recommend that you pick up an MVVM toolkit.

The approach of these authors reflects the reality that a) there is more than one way to do MVVM, and b) you should not attempt to build a serious MVVM app without the aid of a toolkit.  The problem is that, if you are coming up to speed on MVVM, learning the ins and outs of a particular toolkit can be daunting.  What’s needed is a simple MVVM toolkit that comes with a tutorial to take you from square one to building a basic Silverlight application based on the MVVM pattern. Oh and by the way, it would be nice if it included Visual Studio templates and code snippets to make your life easier.

That day has now arrived. I am pleased to announce the Simple MVVM Toolkit for Silverlight, available for download from CodePlex: http://simplemvvmtoolkit.codeplex.com.

It includes a set of helper classes with support for event-based messaging and modal dialogs, an implementation of IEditableDataObject that uses deep copies, and transparent marshaling of events for safe cross-thread calls to update the UI.  It comes with Visual Studio item templates for creating view-models and locators, and code snippets for inserting bindable properties and building out a view-model locator.  While all that is nice, the best part is a tutorial that includes “before and after” versions of a sample application with step-by-step instructions for building an MVVM Silverlight application.  This helps fill the void left by some other toolkits, where documentation and samples may be virtually nonexistent.  I’ve kept things very straightforward in this first phase of the project by implementing a standard n-tier application that uses a basic WCF service to retrieve entities from the Northwind sample database.  In the future I’ll incorporate support for things like dependency injection and WCF RIA Services.

Rather than shying away from some of the more controversial aspects of MVVM, I’ve decided as much as possible to address them directly.  Much of it boils down to your needs and preferences. A good example is going for zero (or almost zero) code-behind.  That might be a laudable goal if you have a team of visual designers using Blend that must be able to work independently from developers.  I’ve found, however, that many shops have developers building the UI.  In this case, achieving zero code-behind results in greater complexity and lowers developer productivity.  On the other hand, putting some UI-related logic in the view still preserves testability and separation of concerns, keeping the application simpler and easier to maintain.  In the Simple MVVM Toolkit I favor the latter approach – although the toolkit does provide some facilities for zero code-behind if you decide to go that route.

Another topic where there are diverging opinions is on how to communicate between various components, such as between the view and view-model or among view-models.  One approach is to use a message bus of some sort.  While that does make sense in many scenarios, especially communicating among view-models, I felt that a simpler approach using events is more practical and easier to use.  For example, when a method in the view-model requires information from the user, it can simply raise an event, and the view can handle the event by showing a dialog and calling back the view-model with the results.  It’s easy to understand and implement, and events can be raised by a helper method in the view-model base class, which guarantees that it fires on the UI thread.

Another area where there are different approaches concerns the use of commands.  Many MVVM toolkits include a delegating command which is used by the view-model to expose a command property that an element such as a button can bind to, so that the click event results in calling a method wired up to the command.  My personal feeling is that using commands for every button click (or other events by means of an event-to-command behavior) requires a lot of extra code in the view-model that is basically unnecessary.  While my Simple MVVM Toolkit does have a DelegateCommand for this purpose, I would suggest using it sparingly, and instead use an event trigger with a CallMethodAction to invoke a method on the view-model directly.  The only time I would resort to a command would be to pass a parameter to a method, where the parameter cannot be bound to a property in the view-model.

So go ahead and download the toolkit, take it for a test drive, and let me know what you think.  It’s not intended as the be-all or end-all toolkit, but it should be enough to get you started building Silverlight MVVM applications that maintain a clean separation of concerns, allow for testability and designability (also called Blendability), and can be more easily maintained over the long haul.  Enjoy.