How to declutter dependencies? I'm running into a problem with my code in a ASP.NET MVC application. Maybe it's not a problem and I'm just being paranoid, but it seems like a problem to me (might be because I've just read the book Clean Code).

I am using the repository-pattern with the unit of work-pattern to abstract the data access. In between my controllers and the repositories I have the service-layer which handles my business logic.

Now my problem is: whenever I have a bigger controller with more functionality it gets cluttered up with service declarations. Here is a little example of what one of my controllers might look like:

public class ForumController
{
    private readonly ForumAnswerService _answerService;
    private readonly ForumThreadService _threadService;
    private readonly ReputationService _repService;
    private readonly IUnitOfWork _unitOfWork;

    public ForumController()
    {
        _unitOfWork = new EFContextUnitOfWork(new MyContext());
        _threadService = new ForumThreadService(new Repository&lt;ForumThread&gt;(_unitOfWork));
        _answerService = new ForumAnswerService(new Repository&lt;ForumAnswer&gt;(_unitOfWork));
        _repService = new ReputationService(new ReputationRepository(_unitOfWork));
    }

    /* more stuff which uses the services above.. */

    protected override void Dispose(bool disposing)
    {
        if (_unitOfWork != null)
        {
            _unitOfWork.Dispose();
        }
        base.Dispose(disposing);
    }
}


This does not seem so bad right now but I had controllers with even more services and with growing functionality I think the list of services might grow even bigger and it does not seem clean to me.

Here are some ideas I have to tackle the problem:


Only initialize services when I actually need them (i.e. in the methods)


that will reduce the number of class variables but I think it might clutter up the methods and make them big and ugly

Combine multiple services 


maybe I just have too many small services and need to combine them, for example combine ForumThreadService and ForumAnswerService to a single ForumService
I don't like that though because of SRP and stuff
that would just move the clutter to the services because I would have to pass multiple repositories to the service

Is that maybe a case where a DI framework would come in handy? Never used one and I only did constructor injection so I don't know..
Nope, that's it. Only got those 3 ideas..


I hope my problem is clear and you guys can point me into the right direction.
Yes, #3 is the one - this is exactly what Dependency Injection/Inversion of Control containers are meant for - removing the assembly part of the services from the main code.

Using an external DI framework will also give you additional benefits, such as stubbing out services while unit testing, allow future extensions to services without changing your main code, etc.

A good start to which framework to use you can find here: How do the major C# DI/IoC frameworks compare?