Modules and the Kernel

Modules

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 INinjectModule interface, but most should extend the NinjectModule class for simplicity. Here’s an example:

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

The Kernel

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 Get() extension method.

(A number of extension methods that can be called against the kernel are contained in Ninject.ResolutionExtensions, if you are using Ninject; then you’ll see these method available to call on the kernel).

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.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! :)

Dynamic Module Loading

The static class Ninject.ModuleLoadExtensions contains a number of IKernel extension methods that instruct Ninject to dynamically find and load modules.

kernel.Load("*.dll");

This call will cause Ninject to search all DLLs in the current directory and load any public INinjectModule classes it finds. The modules should be public and have a no-args constructor.

kernel.Load(AppDomain.CurrentDomain.GetAssemblies());

This method takes a list of Assembly to load, in this example it searches all of the assemblies loaded in the current AppDomain.

Continue reading: Providers, Factory Methods and the Activation Context