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.

Dependency Injection is one of the techniques in software engineering which improves the maintainability of a software application by managing the dependent components. In order to have a better understanding of this pattern, let's start this section with an example to clarify what is meant by a dependency, and what other elements are involved in this process.

Cameron is a skilled carpenter who spends most of his time creating wooden stuffs. Today, he is going to make a chair. He needs a saw, a hammer, and other tools. During the process of creating the chair, he needs to figure out what tool he needs and find it in his toolbox. Although what he needs to focus on is how to make a chair, without thinking of what tools he needs and how to find them, it is not possible to finish the construction of the chair.

The following code is the C# representation of Cameron, as a carpenter:

class Carpenter
{
  Saw saw = new Saw();
  void MakeChair()
  {
    saw.Cut();
    // ...
  }
}

Sarah is a heart surgeon. She works for a hospital and spends her days in the operation room, and today she is going to perform an open-heart surgery. It is a sophisticated procedure, and she needs to focus on the operation itself, rather than finding the tools during the operation. That is why she has an assistant to provide her with the tools she requires. This way, she ensures that the exact tool that she needs will be in her hand by her assistant. She doesn't need to know where the tool is and how to find it. These are her assistant's responsibilities.

This is the C# implementation of Sarah, the surgeon:

class Surgeon
{
  private Forceps forceps;

  // The forceps object will be injected into the constructor 
  // method by a third party while the class is being created.
  public Surgeon(Forceps forceps)
  {
    this.forceps = forceps;
  }

  public void Operate()
  {
    forceps.Grab();
    //...
  }
} 

As we can see, she doesn't need to worry about how to get the forceps; they are provided to her by someone else.

In the previous examples, Cameron and Sarah are samples of dependent components that have a responsibility, and tools that they need are their dependencies. Dependency Injection is all about how they get to the tools they need. In the first example, the dependent component (Cameron) itself had to locate the dependency, while in the second one, a third party (the assistant) locates and provides it. This third party is called an Injector, which injects the dependencies.

Every software application is inevitable of change. As your code grows and new requirements arrive, the importance of maintaining your codes becomes more tangible, and it is not possible for a software application to go on if it is not maintainable. One of the design principles that lead to producing a maintainable code is known as Separation of Concerns (SoC). The SoC is a broad concept and is not limited to software design; but in the case of composing software components, we can think of SoC as implementing distinct classes, each of which deals with a single responsibility. In the first example, finding a tool is a different concern from doing the operation itself and separating these two concerns is one of the prerequisites for creating a maintainable code.

Separation of concerns, however, doesn't lead to a maintainable code if the sections that deal with concerns are tightly coupled to each other.

Although there are different types of forceps that Sarah may need during the operation, she doesn't need to mention the exact type of forceps which she requires. She just states that she needs forceps, and it is on her assistant to determine which forceps satisfies her need the best. If the exact type that Sarah needs is temporarily not available, the assistant has the freedom to provide her with another suitable type. If the hospital has bought a new type of forceps that the assistant thinks is more suitable, he or she can easily switch to the new one because he or she knows that Sarah doesn't care about the type of forceps as long as it is suitable. In other words, Sarah is not tightly coupled to a specific type of forceps.

The key principle leading to loose coupling is the following, from the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software):

"Program to an "interface", not an "implementation"."

When we address our dependencies as abstract elements (an interface or abstract class), rather than concrete classes, we will be able to easily replace the concrete classes without affecting the consumer component:

class Surgeon
{
  private IForceps forceps;

  public Surgeon(IForceps forceps)
  {
    this.forceps = forceps;
  }

  public void Operate()
  {
    forceps.Grab();
    //...
  }
}

The Surgeon class is addressing the interface IForceps and does not care about the exact type of the object injected into its constructer. The C# compiler ensures that the argument passed to the forceps parameter always implements the IForceps interface and therefore, existence of the Grab() method is guaranteed. The following code shows how an instance of Surgeon can be created providing with a suitable forceps:

var forceps = assistant.Get<IForceps>();
var surgeon = new Surgeon (forceps);

Because the Surgeon class is programmed to the IForceps interface rather than a certain type of forceps implementation, we can freely instantiate it with any type of forceps that the assistant object decides to provide.

As the previous example shows, loose coupling (surgeon is not dependent on a certain type of forceps) is a result of programming to interface (surgeon depends on IForceps) and separation of concerns, (choosing forceps is the assistant's concern, while the surgeon has other concerns) which increases the code maintainability.

Now that we know loose coupling increases the flexibility and gives freedom of replacing the dependencies easily; let's see what else we get out of this freedom other than maintainability. One of the advantages of being able to replace the concrete classes is testability. As long as the components are loosely coupled to their dependencies, we can replace the actual dependencies with Test Doubles such as mock objects. Test Doubles are simplified version of the real objects that look and behave like them and facilitate testing. The following example shows how to unit test the Surgeon class using a mock forceps as a Test Double:

[Test]
public void CallingOperateCallsGrabOnForceps()
{
  var forcepsMock = new Mock<IForceps>();

  var surgeon = new Surgeon(forcepsMock.Object);
  surgeon.Operate();

  forcepsMock.Verify(f => f.Grab());
}

In this unit test, an instance of the Surgeon class is being created as a System Under Test (SUT), and the mock object is injected into its constructor. After calling the Operate method on the surgeon object, we ask our mock framework to verify whether the Grab operation is called on the mock forceps object as expected.

Maintainability and testability are two advantages of loose coupling, which is in turn a product of Dependency Injection. On the other hand, the way an Injector creates the instances of concrete types, can introduce the third benefit of DI, which is the late binding. An Injector is given a type and is expected to return an object instance of that type. It often uses reflection in order to activate objects. So, the decision of which type to activate can be delayed to the runtime. Late binding gives us the flexibility of replacing the dependencies without recompiling the application. Another benefit of DI is extensibility. Because classes depend on abstractions, we can easily extend their functionality by substituting the concrete dependencies.

We start our example with a service class in which the concerns are not separated. Then we will improve maintainability step-by-step, by first separating concerns and then programming to interface in order to make our modules loosely coupled. At the final point, we will have our first DI application. The source code for all the examples of this book is available for download on the publisher's website.

The main responsibility of this service is to send an e-mail using the information provided. In order to make the example simple and clear, client initialization is omitted.

class MailService
{
  public void SendEmail(string address, string subject, string body)
  {
    var mail = new MailMessage();
    mail.To.Add(address);
    mail.Subject = subject;
    mail.Body = body;
    var client = new SmtpClient();
    // Setup client with smtp server address and port here
    client.Send(mail);
  }
} 

Then, we add some logging to it, so that we know what is going on in our service:

class MailService
{
  public void SendMail(string address, string subject, string body)
  {
    Console.WriteLine("Creating mail message...");
    var mail = new MailMessage();
    mail.To.Add(address);
    mail.Subject = subject;
    mail.Body = body;
    var client = new SmtpClient();
    // Setup client with smtp server address and port here
    Console.WriteLine("Sending message...");
    client.Send(mail);
    Console.WriteLine("Message sent successfully.");
  }
}

After a little while, we find it useful to add time to our logs. In this example, sending the mail message and logging functionality are two different concerns which are addressed in a single class, and it is not possible to change the logging mechanism without touching the MailService class. Therefore, in order to add time to our logs, we have to change the MailService class. So, let's re-factor this class and separate the concern of logging from sending a mail prior to adding the time functionality:

class MailService
{
  private ConsoleLogger logger;
  public MailService()
  {
    logger = new ConsoleLogger();
  }

  public void SendMail(string address, string subject, string body)
  {
    logger.Log("Creating mail message...");
    var mail = new MailMessage();
    mail.To.Add(address);
    mail.Subject = subject;
    mail.Body = body;
    var client = new SmtpClient();
    // Setup client with smtp server address and port here
    logger.Log("Sending message...");
    client.Send(mail);
    logger.Log("Message sent successfully.");
  }
}

The ConsoleLogger class is only responsible for the logging mechanism, and this concern is removed from MailService. Now, it is possible to modify the logging mechanism without affecting MailService:

class ConsoleLogger
{
  public void Log(string message)
  {
    Console.WriteLine("{0}: {1}", DateTime.Now, message);
  }
}

Now, we need to write our logs in Windows Event Log rather than showing them in console. Looks like we need an EventLogger class as well:

class EventLogger
{
  public void Log(string message)
  {
    EventLog.WriteEntry("MailService", message);
  }
}

Although the concern of sending mail and logging are now separated in two different classes, MailService is still tightly coupled to the ConsoleLogger class, and it is not possible to replace its logger without modifying it. We are just one step away from breaking the tight coupling between the MailService and Logger classes. We should now introduce the dependencies as interfaces rather than concrete classes:

interface ILogger
{
  void Log(string message);
}

Both the ConsoleLogger and EventLogger classes should implement this interface:

class ConsoleLogger:ILogger
{
  public void Log(string message)
  {
    Console.WriteLine("{0}: {1}", DateTime.Now, message);
  }
}
class EventLogger:ILogger
{
  public void Log(string message)
  {
    EventLog.WriteEntry("MailService", message);
  }
}

Now, it is time to remove the references to the concrete ConsoleLogger class and address ILogger instead:

private ILogger logger;
public MailService()
{
  logger = new ILogger();
}

But the previous code won't compile because it doesn't make sense to instantiate an interface. We should introduce this dependency as a constructor parameter and have the concrete object injected into it by a third party:

public MailService(ILogger logger)
{
  this.logger = logger;
}

At this point, our classes are loosely coupled and we can change the loggers freely without affecting the MailService class. Using DI, we have also separated the concern of creating a new instance of the logger class, which includes the concern of deciding what concrete logger to use from the main responsibility of MailService, which is sending an e-mail:

internal class Program
{
  private static void Main(string[] args)
  {
    var mailService = new MailService(new EventLogger());
    mailService.SendMail("someone@somewhere.com", "My first DI App", "Hello World!");
  }
}

The main method of this application is where we decide what concrete objects to inject in our dependent classes. This (preferably) unique location in the application where modules are composed together is named Composition Root by Mark Seemann. For more information on DI, Dependency Injection in .NET, by Mark Seemann is recommended.

A DI container is an injector object that injects the dependencies into a dependent object. As we have seen in the previous example, we don't necessarily need a DI container in order to implement Dependency Injection. However, in more complex scenarios, a DI container can save a lot of time and effort by automating most of the tasks that we had to do manually. In real world applications, a single dependant class can have many dependencies, each of which have their own dependencies that forms a large graph of dependencies. A DI container should resolve the dependencies, and this is where the decision of selecting a concrete class for the given abstraction should be made. This decision is made by a mapping table, which is either based on a configuration file or is programmatically defined by the developer. We can see an example for both here:

<bind service="ILogger" to="ConsoleLogger" /> 

This one is an example of code-based configuration:

Bind<ILogger>().To<ConsoleLogger>();

We can also define conditional rules instead of just mapping a service to a concrete type. We will discuss this feature in detail in Chapter 2, Getting Started with Ninject.

A container has the responsibility of dealing with the lifetime of the created objects. It should know how long an object should be kept alive, when to dispose of it, in what condition to return the existing instance, and in what condition to create a new one.

There are other DI Container besides Ninject. You can find a list of them in Scott Hanselman's blog (http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx). Unity, Castle Windsor, StructureMap, Spring.NET, and Autofac are a few of them:

Ninject is a lightweight Dependency Injection framework for .NET applications. It helps you split your application into a collection of loosely-coupled, highly-cohesive pieces, and then glues them back together in a flexible manner. By using Ninject to support your software's architecture, your code will become easier to write, reuse, test, and modify. Instead of relying on reflection for invocation, Ninject takes advantage of lightweight code generation in the CLR (Common Language Runtime). This can result in a dramatic (8-50x) improvement in performance in many situations. Ninject includes many advanced features. For example, Ninject was the first dependency injector to support contextual binding, in which a different concrete implementation of a service may be injected, depending on the context in which it is requested. Ninject supports most major facilities offered by the competing frameworks (although, many such elements live in extensions: plugin modules that layer on facilities on top of the core). You can have a look at the Ninject official wiki at https://github.com/ninject/ninject/wiki for a more detailed list of Ninject features which makes it one of the top DI containers.

Dependency Injection is a technique to help us produce loosely coupled code by moving the concern of creating the dependencies to another object known as a DI container. In other words, instead of a dependent object to decide what concrete class it needs, it just states the needs as an abstraction, and the injector provides it with the most suitable concrete class that satisfies the needs. Loose coupling is one of the main advantages of DI that leads to extensibility, maintainability, and testability. Late binding is another benefit of DI and dynamic loading of plugins is an example of this feature. There are DI containers other than Ninject, each of which has their own advantages and disadvantages.