ASP.NET MVC: Dependency injection i Controllers

Hej,
Har för tillfället en controller-klass som ser ut så här:

IResourceService _resourceService;
IClientService _clientService;
public ResourceController(IResourceService resourceService, IClientService clientService)
{
        _resourceService = resourceService;
        _clientService = clientService;
}

Inget konstigt, jag skickar in två serviceklasser som instansieras via Structuremap.

Men jag känner nu att ju fler controllers jag lägger till, ju fler serviceklasser behöver jag skicka in i kontruktorerna så min fråga är:
Hur undviker jag det?

Skulle det vara möjligt att ha ett "super" interface som jag skickar in i konstruktorn, typ:

IResourceService _resourceService;
IClientService _clientService;
public ResourceController(ISuperService superService)
{
        _resourceService = (IResourceService)superService;
        _clientService = (IClientService)superService;
}

Eller är det en dålig idé?

Det är förmodligen en dålig ide. En bra riktlinje brukar vara att har en klass mer än 3-4 dependencies som injectas så har du förmodligen fel abstraktionsnivå. Gör du ett superinterface bryter du även mot ISP, Interface segregation principle i från SOLID-principles. Ett anti-pattern i MVC är ju fat-controllers, kanske gör din controller lite för mycket.

Kanske har du inte tänkt till i dina serviceklasser, en klass ska ju ha ett tydligt ansvar, och har de detta så är det ju inget fel att ha dom som just en klass, även om det blir många klasser, och injectar du dem, ja då har du förmodligen ett beroende. Man ser dock rätt ofta att folk missanvänder injections bara för det flyter på när man kör med ett IoC-ramverk, och får fram "constructor over injection" (Har för mig Jeffery Palermo har skrivit en del om det), pg. av att man inte funderat över klassens (i det här fallet controllerns) ansvar.

Red. Jeffery Palermo
http://jeffreypalermo.com/blog/constructor-over-injection-anti-pattern/
http://blog.ploeh.dk/2010/01/20/EnablingDIForLazyComponents.aspx

Tack för tipsen erka. Då ska jag försöka hålla igen på antalet interfaces som injectas.
Om tre-fyra stycken är ok så ligger jag i dagsläget bra till! :)

Hmm, jag hänger inte med fullt, detsto fler servicar behöver du skicka in?

Är det inte så att en Controller har 2-3 st en annan Controller har 2-3 andra servicar?

Nickemannen skrev:

Hmm, jag hänger inte med fullt, detsto fler servicar behöver du skicka in?

Är det inte så att en Controller har 2-3 st en annan Controller har 2-3 andra servicar?

Absolut, så är det.
Det var bara en känsla jag hade, jag har inte kommit så långt i projektet än för att kunna veta.
Känslan var att jag behöver använda och visa properties från flera olika modeller och då behöver jag injekta alla modellers serviceklasser.
Men det är som erka skriver, om man hamnar där så gör nog controllen lite för mycket! :)

Men då gör ju controllern för mkt, sedan ska man ju inte ha en service per entitet.
Eller så har du ingen modell som är anpassad nog för det du vill göra :s

Jag har inte en service per enhet, men bra nära. Alla entiteter av stor vikt har egen serviceklass. Vad som är rätt här och hur man bör tänka är jag lite osäker på.

Vad som är rätt och rätt är alltid it depends ;) Domändriven design pratar ofta om saker som bounded context och aggregate roots. Service är ett namn som ska användas med försiktighet tycker jag, det tenderar allt att ofta användas som namnstandard utan någon tanke bakom det, eller en mindre genomtänk tanke, precis samma sak klasser som tenderar heta något med Manager, Helper etc.

Jag tror DDD-litteratur kan hjälpa dig i rätt riktning, en bra julläsning är Eric Evans bok (Påväg med en ny han missade saker som domain events i den första). Även om inte alla projekt passar för DDD kan man hämta inspiration i vissa koncept

Vad som är rätt och rätt är alltid it depends ;) Domändriven design pratar ofta om saker som bounded context och aggregate roots. Service är ett namn som ska användas med försiktighet tycker jag, det tenderar allt att ofta användas som namnstandard utan någon tanke bakom det, eller en mindre genomtänk tanke, precis samma sak klasser som tenderar heta något med Manager, Helper etc.

Jag tror DDD-litteratur kan hjälpa dig i rätt riktning, en bra julläsning är Eric Evans bok (Påväg med en ny han missade saker som domain events i den första). Även om inte alla projekt passar för DDD kan man hämta inspiration i vissa koncept