Only use a dependency injection container at the root of an application?

Question

normally, I'll use a dependency injection container (unity) in c# like this example:

class SomeClass
{
    private readonly ILogger _logger;

    public SomeClass()
    {
        _logger = DependencyContainer.Resolve<ILogger>();
    }

    public void DoSomething()
    {
        var someOtherClass = DependencContainer.Resolve();
        someOtherClass().whatElseEver();
    }
}

Yesterday, I've read some articles about correct dependency injection with a di container. After this, I know that my example is totally bad. This is not dependency injection this is just something like a service locator.

Okay, how to solve this? I think with constructor injection you can solve this problem easily:

class SomeClass
{
    private readonly ILogger _logger;
    private readonly ISomeOtherClass _someOtherClass;

    public SomeClass(ILogger logger, ISomeOtherClass someOtherClass)
    {
        _logger = logger;
        _someOtherClass = someOtherClass;
    }

    public void DoSomething()
    {
        _someOtherClass().whatElseEver();
    }
}

Now I have the correct implementation of the dependency injection principle. But how to wire up all these dependencies? I have a caller class which resolve all the required decencies of the class "SomeClass":

class SomeClassCaller
{
    public void DoSomething()
    {
        var logger = DependencyContainer.Resolve<ILogger>();
        var someOtherClass = DependencyContainer.Resolve();

        var someClass = new SomeClass(logger, someOtherClass);
        someClass.DoSomething();
    }
}

But this example still use a dependency container as a service locator, which is bad. In nearly every article about this, I've read, that the dependency container should only be used, at the application root/entry points, is this correct?

That means, no class should have the ability the resolve some dependencies with a "service locator" on the fly, like the logger. I've to inject the ILogger into nearly every class through the constructor, to avoid this problem, correct? This way feels really bad, if I take the ILogger through maybe 10 classes into every constructor, isn't it?

So, I've to use a dependencies container only, if I've a complex dependencie graph?

Can someone give me an example how it looks like, if you use a dependency container, only at the root of an application?

Answer 1

Consider these classes, and their dependencies explicitly listed as argumetns to the constructor.

class SomeClass {
    public SomeClass(IFoo foo, IBar bar) {}
}

class Foo : IFoo {
    public Foo(IBaz baz) {}
}

class Bar : IBar {}

class Baz :IBaz {}

The Graph would look like this:

• SomeClass
  • IFoo
    • IBaz
  • IBar

Now, assembling this by Hand means creating instances the whole object graph, with its dependencies:

var baz = new Baz();
var foo = new Foo(baz);
var bar = new Bar();
var someClass = new SomeClass(foo, bar);

Using an IOC container with constructor injection is not really different. The thing you have to grasp is: You pull on one end, and the graph will follow:

container.add(IFoo, Foo);
container.add(IBar, Bar);
container.add(IBaz, Baz);
container.add(ISomeClass, SomeClass);

// now pull on your "Entry Point"/"Bootstrap":
container.get(ISomeClass);

The container will resolve and inject dependencies as needed. You do not have to resolve anything by hand, with one exception: This is your entry point.

Answer 2

The answer depends on one single factor which divides the problem into two branches:

You don't use an IoC framework

If you ever wanted to unit test your whole application, from the application root, then you would indeed use the DI container only in the application main function and pass everything down the line using dependency injection. But I have been developing for several years and I am yet to come to a situation when someone would actually want to do that. To make sure the application works as a whole, you have integration tests.

When deciding whether to use dependency injection for a class or instantiate its dependencies inside (be it by directly calling new or using a DI container), the rule of thumb is to ask whether you want to unit test the class you are creating.

If you want to unit test a class in the future, or perhaps you are even developing using the TDD approach, then DI is the way to go. If you do not care about unit testing the class you are creating, because it is merely a wrapper for 20 other smaller, testable classes, a wrapper acting as a procedure, instantiate its dependencies inside.

You use an IoC framework

If you're using an IoC framework, which is able to resolve dependencies (such as Guice for Java, Ninject for C# or Dice for PHP), use dependency injection for everything.

You will have instantiation in one place, which is great, and if you ever decided to unit test large chunks of your code, you are still able to do so.