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:
- Listar upp alla saker man behöver för att kunna testa, olika instanser och och sådant.
- 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".
- 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å.