Patterns en practices in SharePoint: wat is wijsheid?

Patterns and Practices logoSinds een aantal jaren, eigenlijk sinds SharePoint 2010, ben ik mij steeds meer gaan bezighouden met het al dan wel of niet toepassen van patterns en practices in SharePoint projecten. Voor mij was dit enerzijds een wereld die voor me open ging, maar anderzijds ook voer om over na te denken. Wat is wijsheid? Welke patterns pas je toe? Hoe ‘best’ zijn best practices? Wat soms als waarheid gebracht wordt, blijkt in de praktijk soms erg tegen te vallen.

Een van de aanleidingen waarom ik mij hiermee bezig ging houden is de spaghetti code die regelmatig geproduceerd wordt binnen SharePoint projecten. Een van de redenen waarom dit gebeurt is dat er een vage scheiding is tussen declaratieve configuratie van SharePoint artifacts, business logic en data access in een SharePoint Visual Studio project. Voorbeeld hiervan is het scenario waarin er code moet worden uitgevoerd bij activatie van een feature: je voegt een feature toe (xml), je klikt op ‘add event receiver’ wat een code bestand toevoegt, en je begint met coden tegen het SharePoint object model aan. Vaak groeit een dergelijk SharePoint project uit tot een brei van xml (configuratie), gecombineerd met code die iets in SharePoint doet (vage scheiding tussen logic en data laag).

Het is geen vreemd scenario; er wordt je ‘geleerd’ op deze manier te werken als je zoekt naar voorbeelden op het internet en SDK’s. Dit is iets wat (in mijn ervaring) veel gebeurt, maar wat voor grotere en complexere projecten (wat het snel wordt) funest is voor de onderhoudbaarheid en kwaliteit. Het gebruik van patterns en practices als Service Locator pattern, MVP pattern, repository pattern en verschillende best practices, geeft in dit geval houvast en inzicht in de opzet van je SharePoint project. De patterns zorgen ervoor dat er wordt nagedacht over de plek waarin je bepaalde code toevoegt, hoe dit te onderhouden is en hoe hergebruik wordt gestimuleerd. Ontwikkelaars die bekend zijn met deze patterns zouden in no time hun weg moeten kunnen vinden in een project. Prachtig, in theorie in ieder geval.

Een van de nadelen echter, is dat een project een hoog abstractieniveau heeft. Voor de één een walhalla, voor de andere lastige en moeilijk te doorgronden code. Niet alleen is de hoeveelheid bestanden met code groot, ook komt het vaker voor dat er een groter aantal verschillende Visual Studio projecten gebruikt wordt. Al gauw kan het overzicht verloren gaan. Welke solutions rol je waar uit, en op welke manier? Wat gebeurt er als ik een solution retract of wil upgraden. Welke consequenties heeft een code wijziging? Etc, etc. Soms wordt als argument gegeven dat het gebruik van patterns de goede ontwikkelaars onderscheidt van de mindere. Ikzelf denk dat het meer een persoonlijke voorkeur is.

Inmiddels stel ik mezelf bij elk project de vraag of en welke patterns ik zou willen toepassen. Eerlijk gezegd heb ik hier geen eenduidig antwoord op. Het lijkt alsof de pragmatiek van een project zich constant moet meten met de politiek correcte patterns en practices. SharePoint zelf werkt hierin vaak ook niet goed mee. Zo is het bijvoorbeeld in het Service Locator pattern bijna een vereiste tooling te schrijven om inzichtelijk te maken welke type mappings er gemaakt zijn op welk niveau. Een software factory is in dit geval eigenlijk een vereiste.

Een andere uitdaging is de interactie met de SharePoint UI, en in het bijzonder de client-side rendering. Het is een uitdaging om de patterns goed te laten werken met bijvoorbeeld het client object model van SharePoint. Met elke nieuwe versie van SharePoint wordt er een stap gemaakt in de volwassenheid van het platform, maar komen direct ook de uitdagingen om de hoek kijken als het gaat om custom solutions.

Om enig houvast te krijgen in de toepassingen van patterns en best practices voor SharePoint, is het wijsheid je af te vragen welke meerwaarde brengt een pattern in je project, wat het profijt is in de toekomst en of het de extra investering in tijd waard is. Soms lijkt het of het toepassen van patterns iets is voor de code puristen. In mijn idee wordt er veel te weinig aandacht besteed aan de (soms erg nuttige) patterns. Het blijft daarbij een min of meer persoonlijke keuze binnen SharePoint projecten…

Leave a Comment