Ninject Tips: Some Binding Magic & Kernel Cleanup

I’ve been happily using the Ninject Dependency injection library on my C# project for over a year.

In order to keep my project even reasonably organized, I quickly started using Modules to group together my dependencies. For the most part in my project, my Modules correlate to the first layer of namespaces beneath the project root. Additionally, because of the way I organize my classes (adhering to the Single Responsibility Principle (SRP) and highly compose-able), many of my Modules consisted primarily of stateless SRP classes, whose only injected constructor arguments are other stateless SRP classes. These classes are essentially stateless, and should therefore have singleton implementations. In addition, to make mocking easier, most of them are the sole implementation of an interface.

Conceptually, this is all sound, but it didn’t take long until typing this got really old:

public override void Load() 
{
    Bind.To.InSingletonScope();
    Bind.To.InSingletonScope();
    // ... many more of the same ...
}

A Little Binding Magic

So let’s DRY this up, shall we? How about for a specific Module, we load up all the classes in the namespace and bind them to interfaces?

public override void Load() 
{
    this.Bind(x => x
        .From(GetType().Assembly)
        .SelectAllClasses().InNamespaceOf(GetType())
        .BindAllInterfaces()
        .Configure(b => b.InSingletonScope()));
}

Occasionally I also have classes that don’t implement and interface but that I still want to treat as singletons. Generally these are public classes with no parent class, so I added this bit of logic:

this.Bind(x => x
    .From(GetType().Assembly)
    .SelectAllClasses().InNamespaceOf(GetType())
    .Where(t => t.BaseType == typeof (object) // no parent class
                && t.GetInterfaces().Length == 0 // no interfaces
                && t.DeclaringType == null) // not an inner class
    .BindToSelf()
    .Configure(b => b.InSingletonScope()));

Every now and then I would need a bit more flexibility, so I added the ability to exclude specific classes and to include additional namespaces (for example, to handle classes in other assemblies). The pattern shared by both my above examples ends up looking like this:

public virtual IList Excluding
{
    get { return new List(); }
}

public virtual IList Namespaces
{
    get { return new List {GetType().Namespace}; }
}

public override void Load() 
{
    this.Bind(x => x
        .From(GetType().Assembly)
        .SelectAllClasses().InNamespaces(Namespaces)
        .Excluding(Excluding)
   // now do binding
}

Now when I create a new class conforming to these patterns, I don’t have to worry about setting it up for dependency injection at all — it is done automatically. For example, my original two bindings of ISomeClassOrOther and IYetAnotherClass would be bound to their implementations.

Kernel Cleanup

This was all well and good, but later I noticed that my system tests were leaking memory like a sieve. I wanted to reset the Kernel (the source that provides dependency implementations) between each test run, but my naive implementation of just removing all my references to the old Kernel and instantiating a new one was far from sufficient. When I used some memory profiling tools, I discovered that components in the new Kernels ended up referencing the original Kernel.

Pretty quickly I decided the only safe thing to do would be to maintain the same kernel, but reset all its components. After doing a bit of digging, it turns out that is as simple as:

kernel.GetModules()
      .Where(m => m is MyNinjectModule) // only for modules I created
      .ForEach(m => kernel.Unload(m.Name));
kernel.Components.Get().Clear();

Then I just needed to tell the Kernel to load all my Modules again the same way I did the first time.

On later searching, I found the MockingKernel extension, which would have helped with some of the things I need, but not enough. It resets the cache but doesn’t clear the bindings. So I would still need to reset the bindings manually, or I would need to instantiate a new Kernel. And after what I’ve seen, I wasn’t going anywhere near that.

Don’t Let the Perfect Be the Enemy of the Good

I’ve found Ninject to be very helpful, but also occasionally obtuse. It has a lot of interesting and powerful features for which I’ve barely scratched the surface. On the other hand, even in what I’ve seen, I’ve found it necessary to be careful how I use it. Though I can’t really fault Ninject for that — no library is perfect.

If you ever do find a library that is both incredibly useful and without flaws, let me know. Or better yet, don’t tell anyone and invest all your money in the library’s authors.