I am working on ASP.NET MVC3 solution that uses dependency injection with autofac.
Our controllers are being created by autofac and properly and all required objects are being properly passed in. Those objects usually include services, repositories, and mappers converting domain object to MVC (view) models. So the controller constructor looks somewhat like:
public abcController(
ILogger logger,
IabcRepository abcRepository,
IabcService abcService,
IMapper<AbcDomain, AbcViewModel> abcMapper,
...
)
Unfortunately, in time, those constructor parameter lists tend to grow quite quickly. Some of our controllers expect now 60 or more parameters.
Did we create some anti-pattern here?
EDIT
I should have mentioned that we try to follow thin contoller pattern. Also most of those parameters tend to be mappers – around 66%. The control methods are usually very simple, and follow either this pattern:
- Based on parameters call appropriate service or repository
- Use mapper to convert result to appropriate view model
- Pass view model to view
Or this pattern:
- Receive model from post action
- Use mapper to convert it to appropiate domain object
- Invoke appropriate service or repository with domain object
60 or more parameters is a lot.
In your question you stated “..Those objects usually include services, repositories, and mappers converting domain object to MVC (view) models…”
You’ve got a Fat Controller (not the Thomas The Task Engine kind) but a controller that is doing too much.
The balance I look for is Fat Model skinny controller. Ian Cooper talks about it well in this blog post
You can also look at things such as which parameters are actually cross cuttings concerns.
For instance Mapping and Logging in my mind are cross cutting concerns so you could potentially use Action Filters to clean up your controllers.