Creating a binding factory for Ninject

I had someone send me an e-mail today asking me about configuring Ninject in a real application since most other DI frameworks just have a default config section or file that they just magically read from in order set themselves up. Well, the answer is quite simple, and I think that as a community we have become so used to config files and xml settings that we can forget how easy it is to just configure things in code. I’m going to lay out my DI container that I use in a few of my projects, and it is so simple that you will have a “duh!” moment.

I think another part of it is also that Ninject does not have a single “Factory” that you can request objects from, since in Ninject you can have multiple kernels and multiple modules per kernel. Below is a simple setup with a single kernel and module, but I’m sure you can see how it flesh it out a bit more if you wanted multiple.

First thing I want to do is to make my application DI framework agnostic (You may or may not care about this). So, I do this by creating a class called DIFactory. This class will look something like this (and yes I made a class with static methods, some people might use instance methods. I have actually done this in a few projects, but since our DIFactory is used in tests and we rarely mock it, I am just showing this with static methods):

public static class DIFactory
{               
    public static T Resolve<T>()
    {
        
    }

    public static T Resolve<T>(string name)
    {
        
    }
}

This covers the very basics of what most DI frameworks provide. You can probably already see where this is going, but lets take it further. What this class will allow us to do is just to call:

MyClass variable = DIFactory.Resolve<MyClass>();

And now you can resolve a class by type or by type and name. You can add overloads for passing in a Type object if you need them as well. In the case of Ninject, we could implement this class fully like this:

public static class DIFactory
{
    private static IKernel kernel = null;
    
    public static T Resolve<T>()
    {
        if (kernel == null)
        {
            CreateKernel();
        }
        return kernel.Get<T>();
    }
   
    public static T Resolve<T>(string name)
    {
        if (kernel == null)
        {
            CreateKernel();
        }
        return kernel.Get<T>(With.Parameters.ContextVariable("name", name));
    }

    private static void CreateKernel()
    {
        IModule module = new CustomModule();
        kernel = new StandardKernel(module);
    }
}

So, now that we can resolve any class by calling one of these two methods. Notice that we are only using a very small part of the flexibility that Ninject gives us, but we have to make the call on how important it is to support standard DI framework functions and allow for us to easily switch it out in the future, or to use Ninject specific powers and tightly tie our app to the framework. This is almost always a tradeoff in any tool that we use.

As far as the custom module you see above, it would look something like this:

internal class CustomModule : StandardModule
{
    public override void Load()
    {
        Bind<ICaffeinated>().To<DietCoke>().Always();
        Bind<IEdible>().To<Cheetos>().Always();            
        Bind<ISugary>().To<Cookies>().Always();                        

        Bind<IEditor>().To<Emacs>()                
            .Only(When.Context.Variable("name").EqualTo("Linux"));
        Bind<IEditor>().To<VisualStudio()
            .Only(When.Context.Variable("name").EqualTo("Windows"));
    }
}

This custom module was slightly modified from one of my presentations. And was also used on my screencast series over at Dimecasts.net. Pretty cool stuff. Well, I hope that this cleared something up for a few people, and I hope that this might inspire you to get our and use Ninject in your next application.