How do I inject enough info for all of the classes in my application structure

Question

So, I'm trying (and seemingly failing) to get my head around DI.

I know that I'm supposed to write my controls/classes so that I pass in the appropriate interfaces and the IoC container will work stuff out for me.

And I can see how this would work for, say, an MVC Controller. I don't instantiate this and the system will inject any dependencies in to it that I include in the constructor.

But what happens further down the chain?

My Controller instantiates a class (ClassA) that instantiates a class (ClassB) that needs, say, a Repository.

ATM, I've got code that looks like...

public class ClassB
{
    private IMyRepo repo;
    public ClassB()
    {
        repo = DependencyResolver.Current.GetService<IMyRepo>();
        // ...
    }
}

Now, I'm pretty sure there are going to be gasps in the audience at this, especially as I have to include a reference to System.Web.Mvc at each level of my structure but I'm unsure how else I can do this unless I have something like this ...

public class MyController : MyController
{
    private IMyRepo myrepo;
    public MyController(IMyRepo myRepo)
    {
        this.myRepo = myRepo;
    }

    public ActionResult Index()
    {
        var classA = new ClassA(myRepo);
        classA.DoSomething()
        //...
    }
}

public class ClassA
{
    private IMyRepo repo;
    public ClassA(IMyRepo myRepo)
    {
        this.myRepo = myRepo;
    }

    public void DoSomething()
    {
        var classB = new ClassB(myRepo);
        // ...
    }
}

public class ClassB
{
    private IMyRepo repo;
    public ClassB(IMyRepo myRepo)
    {
        this.myRepo = myRepo;
    }
}

My problem with this is it means that I'm going to be injecting stuff in to the Controller either directly or via a Factory) that it should't know anything about (the repos in this case) and that feels even more wrong.

I can't resolve how I can use DI properly and at the same time, prevent the necessity of exposing bits of the system where they aren't supposed to be.

I would appreciate any help in understanding the whole DI thing enough that I can solve my dilemma or be able to explain why I can't have my cake and eat it

Answer 1

Inject into the classes only what they need:

public class MyController : MyController
{
    private ClassA classA;
    public MyController(ClassA classA)
    {
        this.classA = classA;
    }

    public ActionResult Index()
    {
        classA.DoSomething()
        //...
    }
}

public class ClassA
{
    private ClassB classB;
    public ClassA(ClassB classB)
    {
        this.classB = classB;
    }

    public void DoSomething()
    {
        // ...
    }
}

public class ClassB
{
    private IMyRepo repo;
    public ClassB(IMyRepo myRepo)
    {
        this.myRepo = myRepo;
    }
}

In the application's Composition Root, you can compose the entire object graph:

var ctrl =
    new MyController(
        new ClassA(
            new ClassB(
                new MyRepo())));

Answer 2

You could have the IoC container also inject the implementation of ClassA into the Controller. If you do this, you would not need to provide the IMyRepo into ClassA.

This of course require that ClassA implement an interface and that you register it with the container.

If you don't want the container to provide you with ClassA, another possible way is to have ClassA request the Service Locator to resolve it's dependencies.

public class ClassA
{
    IMyRepo myRepo;
    public ClassA()
    {
      myRepo = Container.Resolve<IMyRepo>();
    }

    public void DoSomething()
    {
        var classB = new ClassB(myRepo);
        // ...
    }
}

This would work, but the service locator pattern is considered an anti-pattern. I would recommend having all you dependencies program against an interface.

Answer 3

If you're using an IOC container you leverage it from the very top of the chain, such as the MVC controller in your example. Assuming your container can construct all of the dependencies successfully the controller will have no knowledge of ClassB.

Your problem is the partial adoption of IOC. Assuming that ClassA is a 'service' class, it doesn't make sense that you new it up in the Index().

Normally it would be more akin to:

public class MyController : MyController
{
    private IMyRepo myrepo;
    public MyController(IMyRepo myRepo)
    {
        this.myRepo = myRepo;
    }

    public ActionResult Index()
    {
        myrepo.DoSomething()
    }
}

or

public class MyController : MyController
{
    private ClassA classA;
    public MyController(IMyRepo myRepo)
    {
        this.classA = myRepo.CreateA();
    }

    public ActionResult Index()
    {
        classA.DoSomething()
    }
}

If your concern is why should i be constructing ClassA that's needed by Index() when I'm on Post() that doesn't use ClassA. That's commonly solved by injecting factories. Most IOC containers provide support for this out of box.

public class MyController : MyController
{
    private IMyRepo myrepo;
    private Func<ClassA> aFactory;
    public MyController(IMyRepo myRepo, Func<ClassA> aFactory)
    {
        this.myRepo = myRepo;
        this.aFactory = aFactory;
    }

    public ActionResult Index()
    {
        var classA = aFactory.Invoke();
        classA.DoSomething()
    }
}

This eliminates paying any cost of constructing ClassA if you don't actually use it.

Your controllers should have few parameters, same for all instantiated 'services'. If you're finding you need constructors with 5, 7, 12, and more dependencies, that's indicative of bad system design.