Mastering Ninject for Dependency Injection: For .NET developers and architects, this is the ultimate guide to the principles of Dependency Injection and how to use the automating features of Ninject in the most effective way. Packed with examples, diagrams, and illustrations.

Although DI is for complex projects, and applying it to a simple project looks like over-engineering, a Hello World project should usually be as simple as possible to show only how a framework works. This project helps us understand how to setup Ninject and run it in the simplest way. So, if you have already used Ninject and are familiar with this process, you can skip this section and continue reading the next one.

In Chapter 1, Understanding Dependency Injection, we implemented DI manually in the MailService class. You remember that we ignored the configuration of SmtpClient to simplify the project. Now, we are going to add the configuration of SmtpClient and implement DI using Ninject.

Let's start by creating the MailConfig class:

class MailServerConfig
{
  public string SmtpServer
  {
    get
    {
      return ConfigurationManager.AppSettings["SmtpServer"];
    }
  }

  public int SmtpPort
  {
    get
    {
      var port = ConfigurationManager
      .AppSettings["SmtpPort"];
      return Convert.ToInt32(port);
    }
  }

public string SenderEmail
{
    get
    {
      return ConfigurationManager 
      .AppSettings["SenderEmail"];
    }
  }

public string SenderPassword
  {
    get
    {
    return ConfigurationManager
    .AppSettings["SenderPassword"];
    }
  }
}

Now, we can update the MailService class and incorporate MailServiceConfig:

class MailService
{
  private ILogger...

One of the responsibilities of a DI container is to manage the lifetime of objects that it creates. It should decide when to create a new instance of the given type and when to use an existing instance. It should also take care of disposing of objects when they are not used anymore. Ninject has a strong support for managing Object Lifetime in different situations. Whenever we define a binding, we can declare the scope of the object instance being created. Within that scope, the object instance will be reused and exist exactly once for each binding. Note that an object is not allowed to have a dependency on an object with shorter lifetime.

As our application grows, the list of service registrations gets longer, and it would be difficult to manage this list. Ninject modules are a good way to segregate our type bindings into distinct groups of bindings, which can be easily organized into separate files. Minimum requirement for a class to be accepted as a Ninject module is to implement the INinjectModule interface. Implementing this interface requires us to implement three methods and two properties each time we need to create a module. It is a good idea to implement this interface as an abstract class once, and extend it whenever we need to create a Ninject module. The good news is that Ninject has already implemented this abstract class, which is named NinjectModule.

Here is how to register our MailService classes in a module:

class MailServiceModule: NinjectModule
{
public override void Load()
  {
    Bind<ILogger>().To<ConsoleLogger>().InSingletonScope();
    Bind<MailServerConfig>().ToSelf...

Ninject supports both code-based and XML configuration. An XML module is like a code module that consists of a list of type registrations via Ninject binding. All bindings can be defined in a single XML document or segregated into multiple documents. The only advantage of using XML modules over code modules is that once we have composed such a document, we can still change our type registrations without having to recompile any part of the application. However, XML modules are not as powerful as code modules; so it is recommended to use code modules unless we need this feature. Even in this case, we can only include those bindings for which we need to change the configuration at runtime in our XML module and keep other bindings in code modules.

It is not difficult to register a few service types, one by one in a small application. But what about a production application with hundreds of services which should be wired to their implementations?

Convention-based configuration allows us to bind a group of services using a convention rather than defining individual bindings for each of them. For example, you can simply ask Ninject to bind all components to their base interfaces like this:

kernel.Bind(r => r
  .FromThisAssembly()
  .SelectAllClasses()
  .BindAllInterfaces());

In order to take advantage of the Convention based configuration, we should add refererence to the Ninject's Conventions extension. We can either use NuGet to install Ninject.Extensions.Conventions or download the binary file from GitHub. We also need to add Ninject.Extensions.Conventions to the using section of our code to make the previous syntax available.

As the syntax indicates, registering a convention-based binding at least consists...

Ninject uses its binding system to map abstract services to concrete types. The core object of Ninject to which we give a service type and get the concrete service is Ninject kernel. Ninject uses the object scopes to deal with Lifetime of the created objects. We can use the predefined scopes or create our custom scopes to define the lifetime of objects created by Ninject. Ninject supports both code-based and XML-based configurations for registering service types. Although XML modules can be modified without having to compile the application, code modules are more powerful and recommended. Instead of registering each service individually, we usually use conventions to register a group of services at a time.