Igår var jag på min första ALT.NET-träff. Det var både intressant och givande. Vi pratade om saker som Nhibernate, DDD, arkitektur, Dependency Injection, automatiserade tester, MVC, Scrum m.m. Nästa träff föreslog jag att vi skulle testa att skissa upp de arkitekturer var och en använder sig av i olika projekt och därefter diskutera igenom dessa. Den träffen ser jag verkligen fram emot. Om du har vägarna förbi så är du välkommen!

Träffarna äger rum under hösten på Bishops Arms (Kungsportsavenyn 36) andra måndagen varje månad. Mer information om träffen finns på denna sida: http://altdotnet.se/pub-gbg.htm

Det är himla kul att ALT.NET-rörelsen börjar växa här i Göteborg. Den har funnits ett tag i Stockholm och andra länder men nu är den här i Göteborg och jag hoppas verkligen att den är här för att stanna och växa. Målet med ALT.NET är att vara en rörelse bestående av .NET-utvecklare världen över. Grundpelarna är kontinuerlig förbättring, sökandet efter bättre metoder och tekniker och en aktiv strävan att öka medvetenheten om alternativa tekniker och synsätt i större kretsar.

Det finns en diskussionslista på Google på följande adress: http://groups.google.se/group/sweden-altnet

Jag gillar inte användningen av BoundFields i GridView eftersom det kräver hårdkodning av property-namnen vilket försvårar förvaltning av applikationen. Skulle man tex byta namn på en property så kommer det inte smälla vid kompilering om man använder sig av BoundFields. Detta är alltså inte önskvärt:

<asp:BoundField DataField="FullName" />

En bättre lösningen är att använda sig av TemplateFields men en klassisk användning av detta ökar kodmängden en del i RowDataBound. Ett exempel:

protected void GridViewX_RowDataBound(object sender, System.Web.UI.WebControls.GridViewRowEventArgs e)
{
    if (e.Row.RowType == DataControlRowType.DataRow)
    {
        Order order = (Order)e.Row.DataItem;

        Label label = (Label)e.Row.FindControl("LabelX");
        if (label != null)
        {
            label.Text = order.X;
        }

        label = (Label)e.Row.FindControl("LabelY");
        if (label != null)
        {
            label.Text = order.Y;
        }

        label = (Label)e.Row.FindControl("LabelZ");
        if (label != null)
        {
            label.Text = order.Z;
        }
    }
}

Förvaltningen av applikationen underlättas lite med hjälp av TemplateFields men det är en del dublicering av kod och kodöverblicken är inte optimal. En bättre lösning är följande:

protected void GridViewX_RowDataBound(object sender, System.Web.UI.WebControls.GridViewRowEventArgs e)
{
    GridViewRowEventArgsCustom eArgs = new GridViewRowEventArgsCustom(e.Row);
    if (eArgs.IsDataRow)
    {
        Order order = (Order)eArgs.Row.DataItem;

        eArgs.SetValue("LabelX", order.X);
        eArgs.SetValue("LabelY", order.Y);
        eArgs.SetValue("LabelZ", order.Z);
    }
}

I detta exemplet har jag skapat en GridViewRowCustom som ärver från GridViewRow. I den nya klassen hittar vi den nya metoden SetValue för att enkelt sätta värdet på tex en label. Genom att använda SetValue-metoden slipper man fem rader kod. I GridViewRowCustom har jag också lagt till properties som anger om raden är en header, datarow eller footer (ex row.IsDataRow istället för e.Row.RowType == DataControlRowType.DataRow).

Här kan du ladda hem GridViewRowCustom-klassen: GridViewRowEventArgsCustom.txt (1,30 kb)

Hör gärna av dig om du gör eller kommer på några förbättringar i området.

Det som jag tycker kännetecknar en bra arkitektur är att den är så ren och enkel som möjligt. En sak som jag tycker har en tendens att smutsa ned och komplicera arkitekturen är en överanvändning av Dependency Injection (DI). Ett populärt syfte med att använda DI är att förbättra och snabba upp testbarheten av systemet genom tex mockning. Om DI till stor del baseras på detta syfte finns det en risk för suboptimering, dvs man optimerar testbarheten av systemet på bekostnad av renhet och enkelhet i den tekniska arkitekturen.

Den största nackdelen med en omfattande klassisk implementering av DI är att antalet interface i arkitekturen ökar. Detta leder i sin tur till att arkitekturen blir mer svårnavigerad för utvecklaren. Detta eftersom interfacen försvårar för utvecklaren att snabbt finna naturliga flöden i systemet. Om utvecklaren tex stegar igenom koden och stöter på ett interface så finns det olika stöd (tex "Find all references" i Visual Studio) för att finna den aktuella implementering av interface:t. Detta arbetssätt kan jag acceptera om DI implementeras av andra syften än för att förbättra testbarhet samt om DI implementeras med rimlig omfattning.
 
Jag gillar heller inte att arkitekturen smutsas ned med kod bara för att förbättra testbarhet av systemet. Testbarhet har egentligen inget med systemet i sig att göra och därför bör den påverka arkitekturen så lite som möjligt.
 
Kan man förbättra testbarhet av systemet utan att arkitekturen tar större skada av det? Det finns lite olika lösningar för detta. Det bästa vore om olika integrationslösningar (som tex Nhibernate, Entity Framework, Enterprise Library, Windows Communication Foundation) erbjöd ett standardiserat stöd för mockning av objekt och andra resultat. Detta vore den bästa lösningen men troligtvis kommer det inte att inträffa inom den närmaste framtiden.
 
En annan lösningsvariant är att skapa en enkel återanvändbar wrapper runt en specifik integrationslösning. En sådan wrapper har i huvudsak två funktioner:
1) Den första funktionen är att autogenerera mock-objektet eller resultatet utifrån olika metoder som anropar den faktiska integrationslösningen. Detta innebär i sin tur att utvecklaren slipper att manuellt skapa mock-objekt. Möjligheten för att skapa manuella mock-objekt bör dock finnas. Det borde även finnas en möjlighet att skapa flera olika mock-objekt för en och samma metod där identifieraren för mock-objektet är inparametrarna till integrationsmetoden.
2) Den andra funktionen med wrappern är att utifrån en enkel configurationsinställning avgöra när den faktiska integrationslösningen eller den mockade varianten ska användas.
 
En sådan här wrapper kommer med stor sannolikhet hålla arkitektur ren och enkel samtidigt som den förbättrar testbarheten av systemet. Wrappern bör inte vara svår att skapa. Själv har jag inte skapat en sådan wrapper fullt ut men jag har gjort några lyckade experiment. Jag började med att pröva spara de olika autogenererade mock-objekten i textfiler men jag kom ganska snabbt fram till att det bästa var att spara mock-objekten och resultaten i en databas. Det blir en liten overhead att använda sig av en mock-databas. Denna overhead är dock relativt marginell och skulle man vilja så kan man bygga in cachning av mock-objekten.

Den wrapper jag gjorde var väldigt simpel men när jag gjorde den så fick jag en mängd nya idéer på hur den skulle kunna förbättras. En sak som jag saknade var tex ett lätt sätt att administrera de olika mock-objekten som skapats. En annan sak som vore bra att bygga in är en möjlighet att upptäcka inaktuella och icke-valida mock-objekt. En integrationswrapper öppnar även möjligheter för tracing, loggning m.m.
 
För att avrunda detta blogginlägg så kan man säga att en förbättrad testbarhet av systemet är förenligt med en ren och enkel teknisk arkitektur. Lösningen för att uppnå denna förening är inte genom en omfattande implementering av Dependency Injection utan genom att skapa wrappers runt olika integrationslösningar.
 
Hör gärna av dig om du testar att skapa en integrationswrapper. Det är alltid intressant att höra andras erfarenheter!

PS. Kanske bör jag tillägga att jag också är skeptisk till en överanvändning av DI för att uppnå flexibilitet i arkitekturen. Allt behöver inte vara flexibelt bara för att det går. I vissa fall behövs det medan i andra fall är det överdesign. Denna överdesign är en slöseri med kundens pengar och något som inte främjar enkelhet och renhet i den tekniska arkitekturen. Flexibilitet låter bra men den har sina konsekvenser som måste beaktas.

En vanlig myt som förekommer om agile är att arkitekturen ofta uteblir. Detta är dock inte sant. Däremot så skall det inte läggas mer tid på arkitektur än vad som behövs. Fokus ska ligga på att uppnå en tillräckligt bra arkitektur, dvs man ska inte överarbeta den (överdesign).

Ett sätt att arbeta agilt med arkitektur är att initialt i projektet försöka bygga upp en grundarkitektur. Man bör som sagt undvika att överarbeta arkitekturen och att lägga för stor vikt på att gissa hur det hela kommer att behöva se ut. Arkitekturen får gärna istället växa fram under resans gång. Skulle man vilja dokumentera den initiala grundarkitekturen så bör dess komplexitet inte vara så hög så att det inte går att beskriva domänen på mer än ett A4 (*). Blir det mer dokumentation så kan det innebära att arkitekturen är överarbetad eller den är på en alltför detaljerad nivå, som tex låg kodnivå.

Om man inleder ett projekt med att göra en väldigt omfattande arkitektur initialt så finns det stor risk att arkitekturen överarbetas men också att verkligheten hinner förändras under den tid det tar att ta fram arkitekturen. Saker som kan förändras är att nya lagar, regler, rutiner eller processer dyker upp och som måste följas m.m. Bland annat därför bör man initialt inte lägga för stor vikt på arkitektur utan istället försöka uppnå en tillräckligt bra nivå på det. I slutändan handlar det om att kunden erhåller så stor avkastning som möjligt på sitt investerade kapital. Detta uppnår man inte om arkitekturen överarbetas men det uppnås inte heller om den underarbetas genom att man bortser från det. Det gäller som sagt att hitta en bra nivå på det hela.
 
*) Detta med A4 var ett förslag som James "Jim" Coplien tog upp på ett seminarium om agile och arkitektur.