Modules and the Kernel

With many dependency injection frameworks, your XML mapping files can quickly grow large and difficult to navigate. With Ninject, your type bindings are collected into groups called modules. Each of these modules represents an independent segment of your application. They can be organized however you like. Modules just need to implement the IModule interface, but most should extend the StandardModule class for simplicity. Here’s an example:

class WarriorModule : StandardModule {
  public override Load() {
    Bind<IWeapon>().To<Sword>();
    Bind<Samurai>().ToSelf();
  }
}

Once you create modules, you load them into a container called the kernel. As the name suggests, the kernel is the core of your application. To request an instance of a type from Ninject, you call the kernel’s Get() method.

This example illustrates how to create a kernel, and activate and use an instance of the Samurai type:

class Program {
  public static void Main() {
    IKernel kernel = new StandardKernel(new WarriorModule());
    Samurai warrior = kernel.Get<Samurai>();
    warrior.Attack("the evildoers");
  }
}

After Ninject works its magic, the result of the call to Get() is a Samurai armed with a Sword. Therefore, the call to the @Samurai@’s Attack() method results in the same output that we saw earlier: Chopped the evildoers clean in half. More information about the full process Ninject follows when Get() is called is described in The Activation Process.

You can create as many modules as you’d like, and pass them all to the kernel’s constructor:

class Module1 {
  public void Load() { ... }
}
class Module2 {
  public void Load() { ... }
}
class Program {
  public static void Main() {
    IKernel kernel = new StandardKernel(new Module1(), new Module2(), ...);
    ...
  }
}

Also, keep in mind that modules are executed just like any other code in your application. Nothing says they’re limited to a boring, static collection of bindings. You can always do more creative things like this:

class WeaponsModule {
  private readonly bool _useMeleeWeapons;
  public WeaponsModule(bool useMeleeWeapons) {
    _useMeleeWeapons = useMeleeWeapons;
  }
  public void Load() {
    if (useMeleeWeapons)
      Bind<IWeapon>().To<Sword>();
    else
      Bind<IWeapon>().To<Shuriken>();
  }
}
class Program {
  public static void Main() {
    bool useMeleeWeapons = false;
    IKernel kernel = new StandardKernel(new WeaponsModule(useMeleeWeapons));
    Samurai warrior = kernel.Get<Samurai>();
    warrior.Attack("the evildoers");
  }
}

This will result in our Samurai being armed with a Shuriken, causing the output Pierced the evildoers armor. If you set the useMeleeWeapons flag to true, the binding would be from IWeapon to Sword, resulting in the output Chopped the evildoers clean in half. Many more advanced scenarios are possible, including reading configuration files, command-line arguments, and the like. And we still haven’t even talked about contextual bindings! :)

Continue reading: Providers and the Activation Context