Dependency Injection börjar användas mer och mer. Jag börjar dock ifrågasätta sättet hur den klassiska implementeringen görs. I vissa fall är den klassiska implementering nödvändig men skulle man kunna göra den bättre och effektivare?

Jag gillar inte när man steger igenom koden och hamnar i ett interface, och därefter blir tvungen att leta efter referenser till detta ("ineffektivitetslampan börjar blinka"). I vissa fall kan jag acceptera detta mönster men inte om det används för tex repositories och där repositoryn använder sig av en ORM eller Entity Framework.

Det finns lite olika syften med Dependency Injection av repositories och det vanligaste syftet är att erhålla snabbare tester genom att mocka objekt, dvs man kör inte integrationstester som i vissa fall är långsamma.

Hur skulle man kunna hantera Dependency Injection bättre? Om man använder sig av ORM eller Entity Framework så borde dessa tekniker ha inbyggd mockning så att man slipper repository interface. Men också så man slipper manuellt skriva mockningsrepositories. Detta borde inte vara så svårt att fixa till. Skulle dessa tekniker erbjuda det så skulle det innebära att kodmassan dras ned en hel del dels genom att slippa interface, manuella mockningsrepositories, metodanropen blir kortare och kodraderna blir färre. Några övergripande fördel som jag ser är att risken för fel minskar, utvecklingen snabbas på samt att läsbarheten och navigeringseffektiviteten ökar.

Om jag spinner vidare och vi tittar på tex Dependency Injection av servicar som bygger på tex Windows Communication Foundation (WCF) så borde även WCF kunna ha en inbyggd mockning för att effektivisera utvecklingen.

Hur skulle man då styra om man vill mocka eller inte? Den spontana tanken är att använda en enkel config-inställning. Så är man i test-projektet och inte ska köra integrationstester då är mockningsinställningen påslagen. Vill man köra integrationstester eller köra applikationen så är den inte påslagen.

Vad tycker ni? Eller vill ni fortsätta att köra med den klassiska implementering av DI? :)

Om du bara använder dig av Interfacens för att du skall kunna använda Mocking så visst har du en poäng där, kan man förenkla det så klart man skall göra det.

Jag använder mig av interfacen av olika skäl, dels så är de ju bra vid DI :) men framför allt så blir uppdateringar av min kod längre fram i projektet så mycket enklare om jag använder mig av Interfacen, och dessutom så kan jag skapa klasser som tar emot ett interface istället för en klass och där med så behöver jag inte bry mig om vad för klass som jag skickar in så länge klassen uppfyller mitt interface.

- M

Jag är inte mot användningen av interface men den klassiska användning vid DI ifrågasätter jag. För den ökar kodmassan m.m.

Jag tror jag förstår vad du menar med andra stycket. Har du något konkret exempel?

Jag har ett exempel i mitt nuvarande projekt. Om vi tar adress som ett exempel. Både en person och ett företag kan ha en adress och dessa skall visas på en sida, dessutom så är det så att det finns flera olika sorters personer och flera olika sorters företag, typ säljare, köpare och agenter, vilka kommer att vara olika objekt med olika egenskaper.

Alla dessa skall visa sina adresser när man vill se informationen om respektive person/företag. För att minska kodmängden så skapar jag en UserControl (WPF) som visar denna information. För varje företag så lägger jag till UserControlen. Då WPF använder sig mycket av DataBinding och man kan binda hela objektet till Formuläret och sedan använda sig av dess properties för att visa informationen så kan man alltså plocka ut denna information direkt i UserControlen eftersom den automatisk kommer att binda till samma objekt som formuläret. Och i min UserControl så börjar jag med att kontrollera så att objektet implementera interfacet IContainAddress och kastar sedan om objektet (som kan vara säljar, köpare, agent eller vad som helst) och kan binda Adress propertyna i min UserControl utan att jag bryr mig om vad för objekt det är som kommer in.

Man kan lösa det på andra sätt (ex: arv), men detta sättet tyckte jag var riktigt smidigt, även om det blir ett extra Interface för varje UserControl som jag vill dela mellan flera olika formulär.

- M

-> Magnus
Har haft lite fullt upp så jag har inte hunnit svara men exemplet du tar upp är ett bra exempel där interface minskar kodmängden. Sådana interface är jag inte emot.

Det jag inte gillar är när det blir för mycket interface. Den klassiska implementationen av DI ökar kodmassan och gör koden svårnavigerad för utvecklaren. DI har inget med applikationen att göra och då tycker jag inte att det ska smutsa ner applikationenskoden. Det jag förespråkar är att det ska vara rent och snyggt i koden.