.NET MVC Controller with multiple Repositories and Services?

Question

Look at my Controller (I'm using Dependency Injection to manager dependencies):

public RoleController(IRoleRepository roleRepository, ISiteRepository siteRepository, IUserRepository userRepository, IDbContext dbContext)
{
    _roleRepository = roleRepository;
    _siteRepository = siteRepository;
    _userRepository = userRepository;
    _dbContext = dbContext;
}

Having a class with many dependencies is a code smell? Right?

But, In my example I need to associate Users and Sites in a Role, then I need to these dependencies to doing this association.

Some people on a mailing list I was told that having too many dependencies is a sign that something is probably wrong. But I see no other way. I separated my responsibilities, there is something in that situation I do not know how to treat? Is something wrong?

Update:

I need Repositories and DbContext because DbContext is my UnitOfWork, repositories don't save.

This example is a simple CRUD with some other functionalities like Associations in the View with a GRID.

Update 2:

I'm using a architecture where my UI Layer is the MVC.

Typically I would only create repositories for aggregate roots, not every entity. I don't know your domain, but my gut tells me you have too many repositories. Additionally, why do you need the repositories AND the dbcontext? Lastly, I typically prefer to do the "orchestration" type business activities in a `Service`, and let the service deal with the repositories etc. The dependency of the controller then becomes only on the service. — Brook, Sep 08 '11 at 19:38
possible duplicate of [In asp.net-mvc, is there a more elegant way using IOC to inject mutiple repositories into a controller?](http://stackoverflow.com/questions/7311623/in-asp-net-mvc-is-there-a-more-elegant-way-using-ioc-to-inject-mutiple-repositor) — Omar, Sep 08 '11 at 19:49
Have a look at: http://stackoverflow.com/questions/2329431/bestpractices-is-it-acceptable-to-use-more-than-one-repository-in-a-mvc-controll — Rookian, Sep 08 '11 at 20:08
Related: http://stackoverflow.com/questions/2420193/dependency-injection-constructor-madness — Mark Seemann, Sep 08 '11 at 20:10

score 8 · Answer 1 · answered Sep 08 '11 at 19:49

I don't believe it's a bad thing, given that you manage dependencies with a good DI framework (i.e. not by using poor man's DI). This way, you explicitly say that the controller will need all these things, because it will. (Note that in many other parts of your application, this might not be a valid argument - the controller is special in the way that it is where you control and direct the program flow, so there's a natural explanation why it needs to see lots of parts of the application...)

However, if you really want to limit the number of dependencies in this specific case, it could make sense to create a MembershipService, which does all the work concerned with Users, Sites and Roles. That would then have a dependency on those three repositories, and your controller would only have a dependency on the membership service.

In response to your update: You could register the unit of work (i.e. the db context) as a "per web request" singleton - this is possible with Castle Windsor and many other DI frameworks. Then you can let your repositories depend on it and do all the changes, and let the controller depend on it for saving, and they will all get the same instance handed to them by the DI framework.

see update, the problem is the MVC is my UI Layer. The argument I received is: The Controllers are responsible for responding to requests from users and should not in principle be related to your domain. — Acaz Souza, Sep 08 '11 at 23:30

.NET MVC Controller with multiple Repositories and Services?

1 Answers1