Dependecy Injection, Unit Testing och Domain Driven Design

Så, då var det första lektionsfria dagen i skolan, mycket krav ställs nu på eget ansvar, självdisciplin och ambitioner. Det är lätt att göra fel saker bara för att man är hemma, men vet man vad man har att göra och sätter upp mål för sig själv blir det enklare. Jag hade många sådana här dagar förra läsåret och lyckades bra med studierna tyckte jag. Kruxet var att försöka skapa balans mellan studier och resten av livet, jag ägnade väldigt mycket av min tid för studierna och glömde nästan att jag hade andra behov också. Visst jag lyckades bra också, med det mesta och tog igen förlorad tid med vänner och familj under sommarlovet. Jag hoppas på att kunna hålla mig lika flitig i år också, men inte tränga bort annat viktigt. Som hälsan och relationer med de som betyder mycket för mig. Sen så förväntar jag mig i och för sig att de personer som står mig nära förstår att jag nu måste tänka på skolan i första hand, eftersom den här tiden är en gåva och den är under en begränsad period, och jag vill göra det bästa av den medan jag har chansen.

Dagarna i skolan har vart mycket intressanta, tempot var ganska högt de första dagarna eftersom vi har pratat mycket om helt nya saker, mycket teori. Nu ska jag börja koda på egen hand och använda de tekniker vi just lärt oss. Detta är kurs i ASP.NET MVC4, men vi har gått igenom följande tre saker som bas för det vi kommer göra nästa vecka då vi kommer gå igenom betydligt mer bekanta saker eftersom jag jobbat med MVC på min LIA: Dependency Injection, Domain Driven Design och Unit Testing, plus en del teori runt detta.

Dependecy Injection (DI):
En typ av Inversion of Control(IoC), som är ett designmöster för att undvika beroenden mellan klasser, och är bra att ha på grund av att det ska vara lättare att byta ut olika delar av koden, utan att påverka den andra. Det gör det även enklare att göra Unit Tests.

Dependency Injection bygger på att man bygger interface istället för klasser för att skicka in som argument i bl.a. metoder. De konkreta klasserna får implementera interfacen, vilket gör att man kan använda olika typer av klasser i samma metod, så länge metoden förväntar sig att ta emot just det intefacet. En så kallad DI-container anänds när programmet körs för att tala om vilken typ av klass som skall användas när ett visst interface skickas in som argument. Körs metoden från till exempel ett Unit Test, så avgör man i testet vad som bör skickas in. Det brukar ofta vara någon fejkad klass som inte är beroende av svar från utanförliggande saker som databas, internetuppkoppling, e-post och massa annat som man kan tänka sig kan strula till det om det inte fungerar.

Domain Driven Design (DDD):
Handlar om att arbeta utifrån en något som kallas domänmodell, där man skapar klasser som beskriver hela applikationen, ofta enkla klasser utan speciellt mycket logik, de skapas ofta som ett eget projekt i den solution som man arbetar med. Domänmodellen innehåller även tjänster och regler som avgör hur viktiga processer ska hanteras. Detta fungerar som själva kärnan av applikationen. Saker som gränssnitt och lagring skall inte finnas här, bara det mest grundläggande.

Unit Testing: 
Är små kodsnuttar som är till för att testa att små delar av en applikation, till exempel metoder, fungerar som man förväntar sig. De skrivs i ett eget projekt i den solution man man arbetar i, och kan köras fler gånger. Man brukar hålla sig till mönstret att man:

1. Listar upp alla saker man behöver för att kunna testa, olika instanser och och sådant.
   
2. Agerar och kör metoden man ska testa, och sparar resultatet i en variabel man vanligen kallar för actual, med vilket man menar att "det här är det faktiska resultatet av den här metoden".
   
3. Jämför resultatet med det resultatet man förväntat sig. Med andra ord kräver det att man har räknat ut exakt vad metoden bör ge för svar när man skickar in de argument man gjort. Alltså ska inte metoderna vara för stora och komplexa, eftersom man då kan få väldigt svårt att räkna ut vilket resultat det borde bli. Ännu en anledning att skriva många små enkla metoder istället för stora komplicerade saker. Om jämförelsen stämmer så går testet igenom, om inte så failar testet och man vet att något inte stämmer i metoden. Mycket användbart vid felsökning.

Nu är det dags att sätta igång med kodningen, och använda denna nya kunskap till något konkret. Jag har några exempel i kurslitteraturen som jag skall göra också.