Using Ninject with MVVM Light

I recently changed jobs and as a result I find myself trying to draw parallels between the ASP.NET MVC development I used to do and the WPF MVVM projects that I am working on now. After spending a couple of weeks reading about WPF and learning the fundamentals I finally sat down to write my first WPF application. I chose MVVM Light as my framework because I felt it had a short learning curve and it was fairly lightweight when compared to some of the other frameworks that are out there.

As a MVC developer, one of my favorite NuGet packages has always been Ninject. Adding Ninject to an MVC application is extremely simple because there is a MVC specific implementation called Ninject.MVC which takes care of all the bootstrapping for you. Once you add the package to your MVC project you simply setup your bindings and your up and running. However, I found myself a little bit confused when I added Ninject to my MVVM Light application. I wasn’t sure how to bootstrap Ninject into the application and since there is no WPF specific version of Ninject I knew I had to do the work myself. However, after a little bit of research I came up with the following solution.

Step 1. Create your Ninject Modules

The NinjectModule class is the easiest way to get your bindings registered. You may have noticed that I have two different modules defined. A “Design Time” module and a “Run Time” module. The DesignTimeContext is a mock database. This allows me to avoid the need to access a real database for design time binding and I also use it for unit testing purposes.

public class DesignTimeModule : NinjectModule {
    public override void Load() {
        Bind<IUnitOfWork>().To<DesignTimeContext>();
    }
}

public class RunTimeModule : NinjectModule {
    public override void Load()
    {
        Bind<IUnitOfWork>().To<MyContext>();
    }
}

Step 2. Wire up the ViewModelLocator

The ViewModelLocator that comes with MVVM Light has a property called IsInDesignModeStatic which you can use to check if you are in design mode or not. We can use this property to figure out if we should utilize the DesignTimeModule or the RunTimeModule that we created in the previous step.

public ViewModelLocator()
{
    if (ViewModelBase.IsInDesignModeStatic)
        _kernel = new StandardKernel(new DesignTimeModule());
    else
        _kernel = new StandardKernel(new RunTimeModule());

    About = _kernel.Get<AboutViewModel>();
    Main = _kernel.Get<MainViewModel>();
}

In my project, I have a ViewModel called ProjectListViewModel and the constructor takes an IUnitOfWork as it’s only parameter:

public ProjectListViewModel( IUnitOfWork unitOfWork )

In order to use this new ViewModel I need to add a property to my ViewModelLocator. As you can see below, I use the Ninject kernel to instantiate a new instance of the ProjectListViewModel. Ninject will also take care of creating a concrete IUnitOfWork implementation and inject it into the constructor based on the bindings we established earlier.

public ProjectListViewModel ProjectList {
    get { return _kernel.Get<ProjectListViewModel>(); }
}

Finally, in the ProjectList View I use the global instance of the ViewModelLocator to assign the ViewModel to the DataContext property.

<Window x:Class="MyProject.View.ProjectList"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
        Title="Projects" 
        Height="450" 
        Width="650"
        DataContext="{Binding ProjectList, Source={StaticResource Locator}}">

I must admit that having a mock database for design time is great because you can pre-populate your repositories with different kinds of data and get immediate feedback on how it works with your UI design. It also gives you the ability to see your databindings at work from within Visual Studio or Blend.