Dependency Injection Container - How to keep available to

Question

When creating an application with Dependency Injection and it utilizes a framework for Dependency Injection such as Unity (or Ninject).
How do you initialize registering the interfaces to the container at the beginning all together and keep them available for the application to use throughout its running lifecycle of the application?
Do you need to pass the DI Container to each method that may utilize dependency injection, or is there some way to make the container globally accessible so that you can register them all together in the beginning and access them throughout running the application without having to continually pass them, and be able to utilize them when ever needed?

Environment: Visual Studio 2015, C#, Microsoft Unity (for DI Container)

Example Code

    static void Main(string[] args)
    {

        // Make Unity resolve the interface, providing an instance
        // of TrivialPursuit class
        var diContainer = new UnityContainer();
        diContainer.RegisterType<IGame, TrivialPursuit>();

        var gameInstance = diContainer.Resolve<IGame>();


        var xotherClass = new AnotherClass();
        xotherClass.TestOtherClassOtherMethod();

    }

------ Another class without context of the Dependency Injection Class ------

    public void TestOtherClassOtherMethod()
    {
        IGame gameInstance = -- -Container is Not available to resolve from in this class ---
    }

Reason: I don't want to need to pass every possible type that I may need later on to each class I load up, I will just want to use the instances when I need them. The more deeper I get into classes, later as the application becomes more complex, I won't want to pass down instances for each type up from the Main() method to each class.

Answer 1

A Dependency Injection (DI) container is just that. A framework for facilitating DI. You don't pass the container around in order to resolve instances of objects. You just request the type you need in your classes constructor and the DI framework will inject the appropriate dependency.

Mark Seemann has written a good book on dependency injection that I would recommend.

You register everything that'll need to be resolved with the container in the composition root. That is to say when your program starts up is when everything should be registered.

Let's say we have the following code:

public class MyClass
{
    public Run()
    {
        var dependency = new Dependency1();
        dependency.DoSomething();
    }
}

public class Dependency1
{
    public void DoSomething()
    {
        var dependency = new Dependency2();
        dependeny.DoSomethingElse();
    }
}

public class Dependency2
{
    public void DoSomethingElse()
    {
    }
}

This gives us the above dependency chain: MyClass -> Dependency1 -> Dependency2.

The first thing we should do is refactor the classes to take their dependencies through their constructor and rely on interfaces rather than concretions. We can't inject dependencies unless there is a place to inject them (constructor, property, etc).

Here is the refactored code:

public interface IMyClass
{
    void Run();
}

public interface IDependency1
{
    void DoSomething();
}

public interface IDependency2
{
    void DoSomethingElse();
}

public class MyClass : IMyClass
{
    public readonly IDependency1 dep;

    public MyClass(IDependency1 dep)
    {
        this.dep = dep;
    }

    public void Run()
    {
        this.dep.DoSomething();
    }
}

public class Dependency1 : IDependency1
{
    public readonly IDependency2 dep;

    public MyClass(IDependency2 dep)
    {
        this.dep = dep;
    }

    public void DoSomething()
    {
        this.dep.DoSomethingElse();
    }
}

public class Dependency2 : IDependency2
{
    public void DoSomethingElse()
    {
    }
}

You'll notice the classes now all take their dependencies through their constructors and do not new up anything. Classes should only take in dependencies that they actually need. For example, MyClass does not NEED a Dependency2 so it doesn't ask for one. It only asks for a Dependency1 because that's all it needs. Dependency1 NEEDS Dependency2, not MyClass.

Now to wire it all up WITHOUT a container we would just new it all up in the composition root:

void Main()
{
    var myClass = new MyClass(new Dependency1(new Dependency2()));
}

You can see how that could get cumbersom if we had tons of classes and depdencies. That's why we use a container. It handles all the depdency graph for us. With a container we'd rewrite it as follows:

void Main()
{
    // the order of our registration does not matter.
    var container = new Container();
    container.Register<IDependency1>.For<Dependency1>();
    container.Register<IDependency2>.For<Dependency2>();
    container.Register<IMyClass>.For<MyClass>();

    // then we request our first object like in the first example (MyClass);
    var myClass = container.Resolve<IMyClass>();

    myClass.Run();
}

In the second example the container will handle wiring up all the dependencies. So we never need to pass Depedency2 to MyClass and then to Depedency1. We only need to request it in Dependency1 and the container will wire it up for us like in the first example.

So in your example we would rewrite it like so:

static void Main(string[] args)
{
    var game = new UnityContainer();
    game.RegisterType<IGame, TrivialPursuit>();
    game.RegisterType<IAnotherClass, AnotherClass>();
    game.RegisterType<IYetAnotherClass, YetAnotherClass>();

    var gameInstance = game.Resolve<IGame>();
    // you'll need to perform some action on gameInstance now, like gameInstance.RunGame() or whatever.
}

public class Game : IGame
{
    public Game(IAnotherClass anotherClass)
    {
    }
}    

public class AnotherClass : IAnotherClass
{
    public AnotherClass(IYetAnotherClass yetAnotherClass)
    {
    }
}

public class YetAnotherClass : IYetAnotherClass {}

In these cases there is no need to pass the container around. You register your dependencies with the container then request them in your classes constructors. If you wish to use the container in the class WITHOUT requesting it through the constructor then you are not doing DI you are just using the container as a singleton service locator. Something that should generally be avoided.

Container as a Service Locator This should be generally avoided but if you want to use the container as a service locator you have two options:

1) Pass the container into your classes that need it through the constructor. You can use the above examples for wiring your classes up for DI. But instead of requesting a dependency like IDependency in the constructor you just pass the container.

public class Game : IGame
{
    public Game(IContainer container)
    {
        var blah = container.Resolve<IBlah>();
    }
}

2) Request your container through a static class:

public static class ServiceLocator
{
    private static IContainer container;
    public static IContainer Container
    {
        get 
        {
            if (container == null)
            {
                container = new Container();
            }

            return container;
        }
    }
}

Register everything as normal in your composition root using the ServiceLocator class. Then to use:

public class MyClass
{
    public void DoSomething()
    {
        var blah = ServiceLocator.Container.Resolve<IBlah>();
    }
}