When should I use dependency injectors like Ninject

Question

Problem

I have some problems to understand when and where exactly in my code I should use dependency injectors like Ninject.

Code

Let's say for example we have the following code:

//WITHOUT NINJECT:     
IMailSender mailSender = new MockMailSender();

//WITH NINJECT:
IMailSender mailSender = kernel.Get<IMailSender>();

This one is not a dependency injection so does it make sense to use Ninject in this scenario?

Another example shows how my code gets really messed up by using a dependency injector:

 public void CalculateRevenueRecognitions(IContract contract)
    {
        //WITH NINJECT
        var kernel = new StandardKernel(new DefaultModule());
        var arguments = new List<IParameter>
        {
            new ConstructorArgument("amount",contract.Revenue),
            new ConstructorArgument("date", contract.WhenSigned)
        };
        contract.AddRevenueRecognition(kernel.Get<IRevenueRecognition>(arguments.ToArray()));

        //WITHOUT NINJECT:
        contract.AddRevenueRecognition(new RevenueRecognition(contract.Revenue, contract.WhenSigned))));
    }

Question

When should I use a dependency injector?

1. on constructor injections, parameter injection, etc.
2. on object creation (do dependency injectors replace classical object creation with new?)
3. are the others?

When shouldn't I use a dependency injectors?

Answer 1

The basic premise is to not rely on concrete classes (like you said newing concrete classes) and to inject implementations (via interfaces). It depends on the specific task you're performing and under what conditions (Windows Service, WCF service, Asp.Net), but in most instances you have an interface with all the methods you wish to expose publicly, like so

public interface IBar {
    void DoStuff();
}

Then you then bind these to a specific class using Ninject i.e.

 Bind<IBar>().To<BarClass>();

So at startup Ninject goes and gets the configured implementation. The plus side to this is your implementation is configured, so it's really easy to swap to another implementation as long as it's implementing the interface. So if you had another class you wanted to now use instead of BarClass, you could just rebind to it i.e.

Bind<IBar>().To<NewBarClass>();

So wherever you need to use this NewBarClass, you'd pass it in like this

public class UserOfNewBarClass {

public UserOfNewBarClass(IBar newBarClass) {
}
   // Use the IBar interface
}

Also, you can mock out the interfaces when testing which means you can isolate single concrete classes and test them in complete isolation. You can do more complex things, which you can learn later like binding based off property values and conditional binding on what you're injecting into.

For entry points consult these

WCF - http://www.aaronstannard.com/post/2011/08/16/dependency-injection-ninject-wcf-service.aspx

MVC - http://www.shahnawazk.com/2010/12/dependency-injection-in-aspnet-mvc-3.html

Windows Service - Using Ninject with a Windows Service

It's quite hard to understand at first but the Container (in this case Ninject) figures out what implementation to inject based off the binding you specify . The end goal is to inject everything your class needs in order to perform it's methods so you can test it in isolation (it also helps keep the class clean and uncluttered). The preferred way is injection via constructor as the class will have all of its dependencies when it's created. Property injection is of course doable but as with properties, you can't really guarantee it to have been set.

Answer 2

I have extensively used dependency injection frameworks in the past. Hell I even wrote one (which performs registration and resolution lightyears faster than Ninject, although I was happy to borrow it's fun unit test model of Ninjas, KiteShields Shuriken, etc.)

These days I hardly ever use a dependency injection framework. Because if I've learned one thing from the use of (heavy) frameworks it is the following:

you have a technology problem. you search and experiment with frameworks that are going to solve the problem for you. you select one and use it everywhere.

now you have 2 problems. your dependency injection framework just caused you to take on a big dependency for your entire codebase.

There is a great SkillsMatter presentation by Greg Young (http://skillsmatter.com/podcast/agile-testing/simple-is-better) on frameworks with statements and opinions that may seem a bit on the extreme side, but quite a few of them, I have learned the hard way, I do agree with.

Answer 3

The thing is, I can't now imagine a scenario where I would just use dependency injection on its own. I'm more familiar with situations where you use Inversion of Control (IoC container which uses DI). In such cases, your code is actually very clean, because you don't have to call the injector for instances. The IoC container will do it for you.

So I would consider, if it is not better to use IoC/DI instead of using just DI. In the end, many successful frameworks use this combination, non of them use just one of the pair (assuming that they use DI at all, because there is actually another pattern which is possible to combine with IoC).