Jeg er for alvor begyndt at bevæge mig ind i .NET-udvikling og
er i den forbindelse igang med at lære en masse nye begreber og
metoder, som, for mange metoders vedkommende, ikke har givet
så meget mening at arbejde ud fra i et ASP Classic miljø (mest
fordi miljøet ikke understøtter værktøjerne til at gøre tingene på
den måde).
Jeg tænker på områder som
- SoC (Separation of Concern)
- DI (Dependency Injection)
- DRY (Don't Repeat Yourself)
- Automatiserede tests
m.fl.
Jeg er klar over at man godt kan udøve ovenstående praksiser i
ASP Classic (og jeg har da i nogen grad forsøgt dette gennem
tiden), men da måden at inkludere kode på er yderst kluntet i mere
komplekse scenarier og muligheden for at benytte objektorientering
er begrænset, kræver det i bedste fald en yderst disciplineret
udvikler at gennemføre dette. Desuden er muligheden for at isolere
koden fra IIS begrænsede i ASP og derfor er unittests af kode som
benytter session, response, request osv. besværlige i bedste
fald.
Begreberne og metoderne er noget lettere at arbejde med i
.NET, som i høj grad understøtter disse. Specielt når man arbejder
med ASP.NET MVC.
En af de metoder jeg er blevet glad for er DI. DI tvinger mig
til at tænke på tingene i mindre og mere afgrænsede opgaver for at
få tingene til at hænge ordentlig sammen. DI øger også testbarheden
af koden, hvilket understøtter et andet af ovenstående punkter.
DI kan gøres manuelt, men det kan hurtigt blive træls at skulle
instantiere objekter alle de steder hvor man skal injicere
funktionalitet, så derfor har jeg været på jagt efter et
DI-framework, som kunne hjælpe med dette.
Jeg har fundet Ninject. Det eneste DI-framework jeg har prøvet,
men jeg fornemmer det skiller sig ud fra mange andre DI-frameworks
i.o.m. det ikke konfigureres i en XML-fil og dermed fjerner evt.
fejl som følge at tastefejl i den tekstuelle XML. Det er i stedet
konfigureret i kode og dermed bliver bindinger testet på
compiletidspunktet, hvilket jo giver en tidligere mulighed for at
fange evt. fejl. Dermed ikke sagt at det fjerner kørselsfejl ifm.
instantiering, men det er en fejlkilde mindre ifht. konfiguration
via XML.
Der findes et hav af extensions til Ninject, herunder til
webforms, mvc3 og azure. Jeg har ikke selv arbejdet i meget andet
end MVC 3 med ninject (ud over et lille testprojekt til webforms),
så jeg har ikke den store erfaring med hvordan det fungerer i andre
sammenhænge, men mon ikke det mest er et spørgsmål om opsætning.
Resten kører nok ens, uanset projektets form, når først
DI-frameworket er initialiseret.
Du kan tjekke ninject ud her: www.ninject.com
