.NetDesign patternsFrameworksSmells of bad codeSoftware architecture

Core [in Dutch]

Het is maandagmorgen. Er schijnt een waterig zonnetje over Ede. Ik parkeer mijn auto op het parkeerterrein van de Reehorst dat verlaten oogt bij de start van de nieuwe werkweek. Ook vandaag is de Reehorst het toneel voor een Software Developers Event. Één sessie in het bijzonder heeft mijn interesse: Addressing non-functional requirements with aspects.

Waarom nu juist deze sessie? Het verhaal gaat over PostSharp, een aspect oriented framework, en wordt gegeven door Gael Fraiteur, de bedenker van het framework. PostSharp is geschreven in C# en is een hele cleane, voor reguliere developers begrijpbare implementatie van aspectoriëntatie. Nadat in mei op een conferentie in Zurich al een presentatie over PostSharp had bijgewoond, schreef ik op een terras meteen al mijn eerste aspect. Heerlijk eenvoudig!

Frameworks. Ik kan er niets aan doen. Ik hou gewoon van frameworks. Heerlijk om te zien hoe developers, teams en project hun generieke problemen oplossen. Of eigenlijk, zoals ze keer op keer dezelfde problemen oplossen. Want wie maakt bijvoorbeeld het id aan van een nieuw domeinobject? De applicatie of de database?

Trechter

Soms levert het kijken naar code uiterst aangename middagen op, zoals bij een recente code audit die ik samen met een collega uitvoerde op een enterprise portal voor een wereldwijd bekend merk. Laat ik het anoniem houden. Een schoolvoorbeeld hoe het niet moet. Meer dan een miljoen regels code. De ontwikkelaars hadden getracht een servicegeorïenteerde software architectuur te implementeren. Waarschijnlijk op aanraden van de architectuurafdeling van het bedrijf. “Wij ontwikkelen hier altijd onder architectuur. Een service georïenteerde uiteraard.” In deze portal betekende dat alle bedrijfsfuncties vanuit de webpagina’s als web service werden aangeroepen. Op zich nog niet verkeerd, al gaf het deployment model in te uitgebreide documentatie geen aanwijzingen voor de noodzaak hiervan. Bijzonder fraai was dat al deze services – 354 in totaal – allemaal op een en dezelfde klasse waren geschreven. Met recht een trechter.

Vorige week verzorgde ik in Antwerpen een tweedaagse training in het pragmatisch toepassen van UML. Ik kom graag in Antwerpen. Fijne terrassen, prima bier. En zo belandde ik aan het eind van een hectische eerste cursusdag op een terras op de Melkmarkt met twee cursisten.


Cafe Pelikaan op de Melkmarkt in Antwerpen

Beiden werken voor een klein bedrijf in Utrecht dat software ontwikkelt voor zorginstellingen en ziekenhuizen. Deze software, zo verhalen de twee functioneel ontwerpers, wordt ontwikkeld in PHP. Ooit gestart door twee techneuten met een goed idee voor een onontgonnen markt en voldoende kennis van PHP is het bedrijf nu vijftig man groot. Maar bij de start gebeurt het! Je schrijft je eerste code en ontdekt dat sommige software herbruikbaar kan zijn. “Hé, we hebben een object Patient en een object Operatiekamer en die worden beide opgeslagen. Laten we dat isoleren.” En voor je het weet ontwikkel je je eigen framework. Met alle bijzondere principes en eigenaardigheden vandien.

Jaloers

Het ontwikkelen van frameworks vergt een heel eigen vocabulaire, patterns en best practices. Al eens naar het patroon layer supertype gekeken? Ook model-view-controllers zijn er in overvloed. En gebruikt niet ieder project een object relational mapper? En of dat nu Microsoft’s Entity Framework , Hibernate of wellicht een eigen implementatie is? Alles is mogelijk! En wellicht maken uw projecten gebruiken maken van dependency injection – het mechanisme waarmee pas op runtime afhankelijkheden worden gelegd. Gebruikt u ObjectBuilder of zijn opvolger Unity? Of dan toch liever open source? Probeer Windsor. Ook bij Microsoft lusten ze wel pap van het schrijven van frameworks. Microsoft – of meer specifiek Scott Guthrie – heeft zich onlangs alweer van zijn beste kant getoond. De beta van Silverlight is de deur nog niet uit, of Scott verlustigt zich al aan zijn volgende framework, getiteld ASP.NET MVC.

Soms ben ik daar stiekum jaloers op. Op de ontwikkelaars van het framework in PHP in Utrecht die daar een op ziekenhuizen gerichte eigen variant van Outlook mee ontwikkelen, als op Gael Fraiteur met zijn PostSharp, maar ook op Scott Guthrie en de andere bedenkers van frameworks bij Microsoft.

Catchy

Er is namelijk niets leukers dan het schrijven van een nieuw framework. Gewoon van scratch af aan. Verzin een catchy naam. Django of Zend. Start met een nieuwe solution in Visual Studio en maak je eerste items aan. Zou ik nu starten, dan zou ik eerst een assembly Core en een assembly Domain aanmaken. En dan een interface IDomainObject definiëren en een klasse DomainObject, die deze implementeert. Met een property Id schat ik in – een value object uiteraard – en een property Title, zoals ook het NakedObjects framework doet voor het eenvoudig representeren van domeinobjecten. En voor de zekerheid overschrijf ik ToString() zodat deze dan mooi Title retourneert. Misschien begin ik vanavond nog wel!

Maar ook voor frameworks geldt: er is een tijd van komen en een tijd van gaan. Op een gegeven moment is de rek uit je framework. De ooit briljante ideëen zijn ingehaald door nieuwere frameworks, die hipper zijn, open source, en uitgebreid gedocumenteerd. Wat te doen? Een complexe keuze. Ontwikkel ik verder aan mijn eigen framework? Implementeer ik daarbij nieuwe features die andere frameworks al kennen? Hoeveel aanpassingen moet ik daar voor maken? Of ontwikkel ik een nieuw framework, dat al deze nieuwe features al standaard in zich heeft, en natuurlijk beter is dan wat de markt nu te bieden heeft. Of stop ik helemaal met het opzettten van frameworks, en ga ik alleen gebruik maken van frameworks van anderen? Of stoten we meteen maar al het ontwikkelwerk af naar India?

Laat ik me er voorlopig maar niet over buigen. Een tijd van gaan? Inderdaad. Tijd om Word af te sluiten en Visual Studio te openen.

Published in SDN Magazine, July 2008.