Inlägg November 2008

2008-11-29 00:10

Dataaccess och kundnytta

Jag startade ett projekt med att använda NHibernate för dataaccess direkt mot tabeller som mappade 1 till 1 mot mina domänobjekt. Det var tidigt i projektet och jag ville fort få fram någon form av riktig upplevelse för kunden, kunden höll i samma veva på att forma den organisation och rutiner som systemet skulle stödja så det var upplagt för många förändringar av datamodellen. En bit in i projektet togs det fram en ny datamodell för databasen av en databasexpert, den var naturligt nog ganska olik den jag startat med. Den modellen tog hänsyn till många aspekter som min saknade.

Jag blev i samma veva införstådd med att driftorganisationen inte accepterade att applikationer fick direktaccess till tabellerna  utan endast via storedprocedures. Hmm, hur går det ihop med NHibernate? När jag fick klartecken från driften att min applikation skulle få hämta data vi vyer men sköta uppdateringarna via procedurer visade det sig att NHibernate hade ett ganska bra stöd för detta. Att hämta data via vyer gjorde det bättre eftersom jag nu enkelt kunde sätta ihop den nya databasmodellen med hjälp av vyer så att den stämde med min datamodell i applikationen. Uppdateringen var dock en annan visa, även om NHibernate stöder att varje klass har en insert, update och delete -procedur så blev det lite bök med det. Det funkar bra om man inte använder identity i databasen utan låtar NHibernate hantera idgenereringen. Så där fick jag göra en fix. Jag såg dock att stöd för Identity kommer med nästa version, förslaget ligger klart i 2.1 Alpha 1.

Allt detta bara för att komma fram till vad jag egentligen ville säga.

Det jag märkt är att dataaccess tar ganska mycket mer tid i anspråk nu när vyer och procedurer måste skapas och underhållas så fort databasmodellen ändras. Jag har inte sett detta så tydligt förut eftersom man sällan har möjlighet att få en så här jämförelse. Om vi bara hade haft mätvärden på farten i projektet. Då hade man kunnat se hur stor skillnaden är, i siffror.

Jag är dock glad att jag skrivit integrationstester för att testa all dataaccess mot känt testdata, annars vet jag inte hur lång tid det tagit att fixa till vyer och procedurer efter databasförändringarna.

Postad av Håkan Alexander

Kommentarer (2)   Kategorier:  NHibernate

2008-11-26 11:09

Rapport från Öredev

Jag var på konferansen Öredev i Malmö förra veckan. Fantastiskt! Vilken lineup med talare dom fått dit. Några exempel på dem jag lyssnade till. Eric Evans, Dr Jeff Sutherland, Jimmy Nilsson, Ayende Rahien, Ted Neward, Robet C Martin, Diana Larsen, James Bach, Kevlin Henney, Scott Bellaware och Avegas Joakim Sundén.

Mina favoriter:
'Active Record' med Ayende Rahien. Han började med att hävda att det är helt onödigt att skriva dataaccesskod, det hanterar olika frameworks åt oss så vi kan koncentrera oss på kundnytta i stället. Sen visade han hur det kan gå till med hjälp av Active Record som ligger ovanpå NHibernate. Fantastisk uppvisning i hur man hanterar tangentbordet och utvecklarverktygen.

'DDD Panel' Eric Evans, James Coplien, Randy Strafford och Kevlin Henney. Hur mycket erfarenhet får det plats på ett podium?

'ALT.NET Panel' Scott Bellaware, Glen Block, Ayende Rahien och Joakim Sundén. Intressant eftersom Scott och Ayende är väldigt kritiska till det som Microsoft släpper i från sig vad gäller verktyg och practises att få höra att det faktiskt finns krafter inom Microsoft som vill förändra och förbättra de verktyg vi matas med.

'The Power of Value' med Dan Bergh Johansson. Utmärkt inblick i varför man inte skall skicka runt strängar och intar i sin applikation. Han gjorde det med väldigt bra inlevelse och engagemang.

Genomgående kan man väl säga att det var fokus på att optimera kundnytta, skriv inte kod för saker som redan är hanterat. Tex dataaccess, control containers osv osv. Använd TDD för att stödja dig i att skriva bättre kod med lösare kopplingar och framförallt ger dig en trygghet i att ständigt förbättra kodbasen. Som Uncle Bob(Robert C Martin) uttryckte det, tänk om vi varje gång vi checkar in vår kod har städat och gjort den lite bättre och mer läsbar.

Det var en mycket bra och stimulerande vecka(4 dagar).

Postad av Håkan Alexander

Kommentarer (0)   Kategorier:  Oredev2008

2008-11-08 04:17

ASP.NET MVC är det bättre?

Är det nya MVC ramverket för ASP.NET bättre än det traditionella WebForms?

För att svara på det behöver man naturligtvis definiera vilka kriterier som gäller för bedömningen. I mitt fall så är nummer ett hur förvaltningsbart systemet man lämnar efter sig är. Jag har så många gånger stött på system med massor av databasanrop, beräkningar och annan afförslogik kodad direkt i codebehind filerna. Det är mer regel än undantag att sådana system innehåller redundant kod, och redundant kod är det värsta som finns när man förvaltar kod som någon annan skrivit.

Att bygga system som har enhetstester för majoriteten av koden är det bästa sättet vi har idag att lämna ifrån oss system som är förvaltningsbara. Den största vinsten med TDD är inte i utvecklingsfasen, även om det finns många vinster även då, utan för den som skall ta över. Vid vidareutveckling och buggrättning är det ovärdeligt att kunna köra igenom testsviten och få ett OK på att förändringarna inte ställt till några problem i andra delar av systemet. Eller för den delen fått önskad effekt även där, vilket ju är det man oftast missar vid ändringar i system med mycket redundant kod.

Åter till frågan i rubriken.

Vad är då skillnaderna mellan MVC och WebForms som kan hjälpa oss att leverera system som är mer förvaltningsbara? I MVC annvänds inte sidornas codebehind, alltså det går men det är inte lika naturligt med MVC. Med MVC så kan vi enkelt enhetstesta den kod som används för att hämta eller bearbeta det data som utgör ett anrop till en webbsida, det är inte enkelt med WebForms. Det är en stor fördel.
En annan fördel är att MVC konceptet är mer lämpat för websystem genom att det är mer stateless än WebForms, Detta medför att det krävs mindre kod för att hantera renderingen av sidorna. Mindre mängd kod är lika med färre buggar.
Däremot är det naturligt att med MVC skriva renderingskoden så som man gjorde i ASP blanda klienttaggar med serverkod, det tycker inte jag om eftersom det snabbt blir grötigt och svårt att läsa. Där skulle man vilja hitta bra sätt att testa även den koden.

Min uppfattning är att MVC underlättar betänkligt om man arbetar testdrivet och har en ambition att få stora delar av grässnittskoden testad. Dessutom känns det mer naturligt att koda stateless än att försöka härma windowsprogrammering som vid WebForms. Jag tror att vi snart får bra sätt att koda även gränssnitten testbart. Med hjälp av den stora communityn som börjat använda MVC och som är testfokuserad får vi snart goda exempel på det. Så i slutändan är det som alltid upp till projektgruppen och den ensklide utvecklaren, snarare än vertyget, att göra systemet bättre och lätt att förvalta.

Postad av Håkan Alexander

Kommentarer (0)   Kategorier:  ASP.NET MVC    TDD