Just nu sitter jag och kodar på ett litet tillägg till kod som importerar filer in i det system som jag jobbar med. Kunden behöver importera filer även i ett nytt format som de inte har gjort tidigare. Att skriva koden för att importera det nya filformatet är enkelt och smidigt då jag bara behöver ärva av ett interface, implementera logiken och sedan använda mig av dependency injection i den klass som har hand om importering av filer. Allt detta är redan tänkt på innan så inga ändringar behöver göras.

Däremot så har den klass som har hand om själva importeringen även idag hand om validering. Detta är något som så klart bryter mot principen om separation of concerns men detta har inte varit till några problem hitills. Min kollega föreslog däremot att samtidigt som vi implementerade importeringen av det nya filformatet skulle vi kanske refaktorisera om och ta ut valideringen från den klass som har hand om importeringen av filer. Något jag tyckte var en ypperlig idé då detta är en ganska enkel refaktorisering som ändå gör väldigt mycket för att förbättra koden.

Min första tanke var att ta ut koden till en egen klass för att sköta valideringen av den inkommande datan. Ett ganska självklart val som nog skulle fungera bra. Vi har idag även varit ganska defensiva i koden och använt oss av design by contract mycket vilket man skulle kunna utöka för mer ren validering då de i mycket kompletterar varandra. Design by contract är en sorts validering. Detta kändes dock inte bra då den klass som har hand om att importera filer även i fortsättningen skulle ha hand om valideringen också. Jag tillät mig därför att utforska ämnet lite mer för att se ifall det fanns några bra idéer och saker man kanske bör tänka mer på.

Jag började att söka lite på Google angående data-validering i allmänhet samt i dotnet och till sist även i Java. Inget av det lilla jag hittade var direkt något som gav några bra resultat som kunde tillföra något nytt för att förbättra på hur jag tänkt lägga upp data-valideringen. Jag tog dock sen till mitt hemliga knep när den allsmäktige Google inte vill ge resultat, böcker! :-)

Mer...

På CodeCamp var det bland annat en session som tog upp felhantering och hur prestandakrävande det är när man kastar fel.
Strax efter det uppmärksammade jag följande fel som dök upp lite här och var i mitt projekt:

A first chance exception of type 'System.Threading.ThreadAbortException' occurred in
mscorlib.dllAn exception of type 'System.Threading.ThreadAbortException' occurred in
mscorlib.dll but was not handled in user code

Efter lite googlande hittade jag att det var response.redirect som är designad att kasta det eventet. Dock kan man komma runt detta genom att skriva

response.redirect("myPage.aspx", False)

istället för

response.redirect("myPage.aspx")

Detta är en enkel sak man kan göra för att spara prestanda och är nog bra när man har många samtidiga användare.
Man får bara tänka på att tråden då inte avbryts utan den efterföljande koden kommer att exekveras.