MVC lots of services make the controller constructor very large . .

Question

i wind up having about 20 different parameters in the constructor of the model class, one for each service? Is this normal or a sign that something is off.

Answer 1

You might try consolidating some services or think about refactoring the controller-view parts in to smaller scoped components. Also, a dependency injection style framework like Spring can help with things like this.

Answer 2

As @Matt said a dependency injection could help you here and sprint.NET is a good one and there are several others.

Seeing as you mention MVP in particular, you should at least look at Ent Lib 4.1 which now has Unity, Microsoft's take on DI. Their codeplex site is probably a good place to start if this is new.

There are also software factories that integrate with visual studio and give you tools for creating MVP for web sites as linked or web services. These come from pattern and practices too.

Answer 3

Allthough I don't know your setup. 20 seems a bit much I think you go against the SRP (Single responsibility priniciple). But since I can't see your code it is impossible to tell. If you really need all these services in that one model class then perhaps you need to put them in a factoryclass and use that as a parameter.

It is hard to give any good answer on this since we don't know your domain.

Answer 4

I think, categorically, that your controller is interacting with too many services. I've not seen your code - so I'm going off assumptions - but it seems to me that your controller is composing business logic by calling numerous "small" services, rather than drawing on fewer, "larger" services that compose business logic from the smaller services.

Have a look around for information about "orchestration services" vs "entity" or "capability" services and you'll see what I mean. If you create orchestration services that provide your controllers with the logic they require, your architecture is improved because your controllers really should not contain any business logic at all.

I really think that the number of services you consume is the issue here. IoC containers may go some way to resolve how you bind types to your injection parameters etc., but I think the problem is your architecture at this point.