CSLA og design odours
På arbejde har vi ansat en ny medarbejder, som vi forventer os meget af. Han skal blandt andet få gennemført Agile metoder, patterns mv. Hans første gerning har været at finde tre bøger, som vi læser alle sammen. Et af de begreber jeg har taget med mig er “design smells” eller ting, der lugter i et givent arkitektur og eller kode valg. De ting, der gør at advarselslamperne begynder at lyse (eller blinke vildt…).
Jeg har tidligere lovprist CSLA for at være et gennemtænkt framework for forretningslogik. Jeg synes for så vidt stadig at tankegangen bag er fin - men efter at være blevet klogere (og især efter at have sat mig ind i en række ting i version 3.5 af .Net frameworket) er jeg nået frem til, at jeg vil foreslå at skrotte CSLA. Ikke fordi det ikke virker, men fordi der er 3 større problemområder:
1. Hængende bagud-kompabilitet. CSLA har eksisteret siden version 1.1 af .Net frameworket. Derfor er der en del ekstra systemkald, for at gøre omstillingen fra projekter med den gamle version til den nye version så smertefri som muligt. Det vil sige, at der er en række funktioner som egentlig er forældede, men som stadig understøttes. Det er i sig selv ikke et problem, som ikke kan løses ved uddannelse - men det gør det svært at bruge andres erfaringer.
2. WPF. WPF er multi-trådet bag skærmen. Det giver en række problemer især med sikkerhedsmodellen, som er valgt i CSLA. (Det rækker for vidt at beskrive det i detaljer, men det handler om at man ikke kan være sikker på at en given tråd er korrekt auth’et.) Det vil sige, at hele det område af CSLA stort set er værdiløst i dens nuværende form.
3. Silverlight (og til dels WPF) kører som udgangspunkt i en Internet sandkasse, som ikke tillader reflection i særlig vidt omfang. Eftersom CSLA benytter meget refleksion, kan det per definition ikke anvendes til en ren web-klient der anvender Silverligt eller WPF.
De tre punkter er i sig selv væsentlige, fordi det decimerer værdien af et stort (og tungt) framework, men det sidste punkt som er på min agenda, er en ‘ny’ ting, jeg har læst mig til. Det er en stor del af Agile processer. Needless Complexity. Altså, overdreven teknisk løsning på et simpelt problem. CSLA er bygget til konkrete klasser - og ikke abstrakte klasser eller interfaces. Derudover anvendes mobile objekter, som serialiseres i vidt omfang for at understøtte en høj grad af mobilitet med hensyn til hvordan data skaffes (remoting, webservice, lokal klient osv.). Det gør vedligeholdelse til en stor tung opgave og mindsker fleksibiliteten.
Alt i alt reducerer det CSLA til at DataBinding er fuldt implementeret, valideringsregler, fuld understøttelse af ‘aggregater’ (objekter, der indeholder andre objekter - bruges især inden for Domain Driven Developement) samt en understøttelse af mange forskellige scenarier for data-fremkomst i den samme løsning. Som jeg i senere indlæg vil belyse, er databinding-issues nemt overvundne i WPF, valideringsregler ligeså - hvilket ender os tilbage ved at værdien af CSLA ikke står mål med investeringen af kompleksitet og tid.
Så, CSLA er på vej ud. Jeg blev klogere af at læse bogen (og dermed tankegangen) bag det, men nu har det udlevet sin rolle. Det kan sagtens være at det får en revival senere (selvom det er tvivlsomt med den bagage af bagud-kompabilitet, han slæber med sig), men for nuværende er projektet (i hvert fald for os) kollapset under dets egen vægt.