I attended a talk Jonas did last week on MVVM and it got me excited enough to explore it myself. His blog has a wealth of information, and it has all been summarised in his latest post. By reading his blog and many other bits and pieces around the web i was able to get this working myself. I’m going to put it all together into one blog post to give a complete look at how to incorporate all of it together. I aim to show how it all hooks in together and not just show a diagram saying that you should split things out.

Presumably you already have an idea of what Model/View/ViewModel is. The background and reasoning behind it is beyond the scope of this article, but here is an article I recommend. And also all of Jonas’s articles. But basically MVVM + Dependency injection allows your applications to be loosely coupled with the GREAT advantage that all of your code can now be unit tested, since the UI is just databinding to your classes.

Architecture

The application is going to look like the diagram. It will be split up into the usual Model/View/ViewModel components, but I aim to show all of the supporting code that is needed to get it all working.

The application will be a HR system which just show a list of all the employees. I am just going to implement this single method to try and keep this example as simple as possible

View

Page.Xaml. This is a normal silverlight XAML page with our UI components. However we are going to get it databind to our ViewModel and have it auto refresh itself when the data changes rather than doing this by ourselves manually

Model

This is our underlying data that we want to our application to somehow show. Here it will be our HR system. This worries about how to retrieve/add/modify the data.

ViewModel

This sits between the Model and the View. The point of this is to give a specific ‘View and state’ of our Model to the view. The View just wants to display data, it doesn’t want to care about how to retrieve things, so the ViewModel handles all of this for us.

Dependency Injection

Rather than hard coding all of the connections between the Model, View & ViewModel. We can use ‘Dependency Injection’ to insert the class for us. This allows us to be able to use other classes when unit testing, or at designtime vs. runtime.

We will use DI to connect the ViewModel to the View(Page). And to connect the Model to our ViewModel. I have created a few versions of the model which we can swap around.

They all should be self explanatory. But HRSystemSQL retrieves the results from a SQL database. HRSystemMemory gets it from a list in memory. And MockHRSystem is used for sending through precanned data for testing purposes or for our designtime experience.

So we can see that we can switch out the actual implementation of our Model and it will still work as we are programming against an interface. We don’t care if we are retriving from a database, or from a webservice, etc.

Here is the implementation of the mock class that will be used to display data for us at design time in blend, or when we are running unit tests

MVVMTestModule

We’re done with most of the code required to actually get the data that we want. Now we need to say how to wire it all up, since we haven’t used any code in the code behind files. First we are going to define how the dependency injection is setup in the application. I am using Ninject to handle this, so it will look like this

To simplify things, I’m avoiding using the SQL implementation and will just be holding a list in memory by using the HRSystemMemory implementation.

ServiceLocator

We are using dependency injection, but we still need to tell silverlight once where to look for the class that will handle all of the dependency injection niceness for us. Jonas does a great job explaining why we have one, but here is what we will use in this example

Silverlight is now able to get Ninject to pass to us our new PageViewModelClass that has been setup with the correct Model being passed in (Mock or a proper implementation) based on if we are in blend or running the app.

Further work

This was just a quick rundown on how to create a complete MVVM application that is fully testable. New concepts weren’t meant to be introduced here, just showing how it all works together. As shown in the initial diagram, converters can be used to do more complex mappings between the ViewModel and the View. We still haven’t said how to send events through (like clicking on a button to refresh the data, or adding new data). If there is enough interest, I’ll tie that into this example in another blog post

Like this:

Related

Post navigation

12 thoughts on “Silverlight MVVM + dependency injection”

Nice post. Have been looking for good examples of MVVM that aren’t to complicated or leaves 50% to your imagination. If you wanna throw in some examples of how you use converters, by all means go right ahead :-). Some examples of how to communicate between usercontrols using MMVM would be nice since I haven’t found anything useful i.e. can we communicate between usercontrols and still keep our codebehid clean?

Great post connecting all the dots of the MVVM puzzle nicely! Silverlight and WPF are still young technologies, and best practices is yet to be discovered. So early thinking and exploring like this is the way forward.

Looking forward to catch up at the Silverlight UG meeting in Nov if you’re going 🙂

I wonder if you would take a moment and comment on a screenshot of a solution I built based on your article:

This builds and runs just fine after I adjusted all of the namespaces.

I’m new to Silverlight, and new to MVVM, so my thinking is that Model ends up being in a class library project and a second Silverlight Class Library project with classes linked to the main class library for the ViewModel stuff to reference, and the HSSystem stuff ends up being in the Web project (or a separate project) as a web service. Am I getting warm ? Where should the NInject related stuff (MVVMTestModule and ServiceLocator) go? Thanks.