Dependency Injection With Ninject

Back to: Dependency Injection By Hand

Rather than spending time doing the “busy work” of creating and connecting your objects by hand (and reworking lots of such boilerplate for a few minutes or hours whenever you change interdependencies between your components), you just get Ninject to figure it out for you.

How Ninject constructs your types for you

Ninject doesn’t do anything crazy like rewriting all your assemblies and replacing all instances of new with a redirection to it – it simply gets asked (generally implicitly via one of the extensions, e.g., Ninject.Web.Mvc ) to resolve a service. How does it do this? By calling one of the constructors on your type, just like you would if you were doing Dependency Injection By Hand. (It doesn’t use Reflection though – it uses .NET expression compilation/LCG to make it almost as fast as coding it by hand.)

When asked to instantiate an object, Ninject will look at the type’s available public constructors and pick the one with the most parameters it knows how to resolve — or the parameterless one if there aren’t any suitable ones (there’s an attribute that can be used to override this – see Constructor injection for the nitty gritty).

What this means is that in the vast majority of cases you need to do little if anything to the service classes you want to resolve and have dependencies injected into in order for Ninject to be able to instantiate your objects; you normally don’t change your classes or have any need to reference Ninject assemblies, classes, attributes or namespaces.

How Ninject decides what types to use for type and interface/abstract dependencies — type bindings

The most common thing you need to do is when the parameter being injected is specified as an interface – in that case we need to let Ninject know which concrete type to use to satisfy the interface. So if we have a service class as follows:-

class Samurai 
{
    readonly IWeapon weapon;
    public Samurai(IWeapon weapon) 
    {
        this.weapon = weapon;
    }

    public void Attack(string target) 
    {
        this.weapon.Hit(target);
    }
}

and we want to grab one like this:-

IKernel kernel = new StandardKernel();
var samurai = kernel.Get<Samurai>();

In the above case, Ninject will select the single constructor defined as the one to use. Next, it tries to resolve a value for each of the constructor’s arguments – in this case, there is only one argument to resolve: IWeapon. But wait a second… IWeapon is an interface. You can’t create an instance of an interface itself, so how does Ninject know what implementation of IWeapon to inject?

This is accomplished through type bindings. A type binding (or just a binding) is a mapping between a service type (generally an interface or abstract class), and an implementation type to be used to satisfy such a service requirement (or instructions for how to decide which one via ToMethod as we’ll see later). Bindings are typically expressed via Ninject’s fluent interface. For example, to arm our Samurai with a Sword, we could declare the following binding:

Bind<IWeapon>().To<Sword>();

This binding means that whenever Ninject encounters a dependency on IWeapon, it will resolve an instance of Sword and inject it. This dependency resolution process is a recursive one; that is, if Sword has any dependencies of its own, they will also be resolved before the constructor of Samurai is called. (Also, if the dependencies of Sword have dependencies of their own, they will be resolved in turn, and so on.) In this way, Ninject can wire up an entire graph of objects for you, with minimal work on your end. You just need to set up the path, and Ninject will follow it.

The concept of type bindings is common in dependency injection containers / frameworks. However, some existing frameworks rely primarily on XML mapping files to set up the bindings between types. Through its fluent interface, Ninject allows you to take advantage of the features of your language (like type-safety) and your IDE (like IntelliSense and code completion).

Advanced type bindings

If you’re just trying to get the hang of dependency injection, we suggest skipping straight to the next section on Injection Patterns and coming back here later – this covers advanced aspects and capabilities of the Ninject type binding mechanism. It’s only important to understand this if you’re going to have extremely complex scenarios or you’re trying to compare DI containers having learned another one first.

Using the overloads with Type parameters instead of the generic methods

If you prefer, there are equivalent overloads of the Bind<T>() and To<T>() methods that are not generic methods, which can be useful for automating bulk binding of items you are discovering or scanning from other sources, e.g., one could do the binding above as follows instead:-

Bind(typeof(IWeapon)).To(typeof(Sword));

Skipping the type binding bit — Implicit self-binding of concrete types

TDD and interface-based programming styles often mean you’re generally most commonly depending on interfaces. However, if the type you’re resolving is a concrete type (like Samurai above), Ninject will automatically create a default association via a mechanism called implicit self binding. It’s as if there’s a registration like this:

Bind<Samurai>().To<Samurai>();

for every concrete type you ever try to resolve. Bear in mind that only concrete types can be self-bound; abstract types and interfaces won’t work (though there are a variety of Ninject extensions available that e.g., allow one to plug in Convention over Configuration based policies). Or… as with most things in Ninject, you can plug in your own strategy if you have specific requirements (but that customizability isn’t in your face until you need it).

Implicit self-bindings are generated in the default Object Scope (we’ll discuss that shortly). If necessary, you can override that by adding a binding of your own of the form:

Bind<Samurai>().ToSelf(); // TODO add your rule overrides at the end, e.g. .InSingletonScope();

Registering more than one type binding for a service — contextual binding

You can also have multiple bindings for a given service type, controlled by conditions that examine the context in which the instance is being resolved. This is the contextual binding system mentioned earlier, and is the key to unlocking the full power of Ninject. Don’t worry, it’s discussed in excruciating detail later. :-)

Registering more than one type binding for a service — plugin models

In some cases, you want your service to get a list of n related dependencies rather than just one. This is accomplished by performing 0..n type bindings and then having your service type take a parameter of type T[], List<T> or IEnumerable<T>. See Multi Injection for details.

Continue reading: Injection Patterns