ASP.NET onder de Motorkap: Het Provider Model Nader Bekeken

Door Michiel van Otegem
19 juni 2009

Het Provider Model Design Pattern dat in ASP.NET 2.0 werd geïntroduceerd wordt door sommigen geprezen en door anderen vervloekt. Zoals zoveel dingen geldt dat het Provider Model soms heel goed voldoet en soms absoluut niet. Het is aan ons als ontwikkelaars om te bepalen wanneer we het wel of niet moeten toepassen. Daarom is het belangrijk om de voor- en nadelen goed te kennen.

Het Provider Model legt een expliciete scheiding tussen de API en de implementatie daarvan, net zoals een interface dat doet. Wanneer we werken met een interface is het onze taak om objecten te gebruiken die voldoen aan dit interface. Bij de binding tussen interface en implementatie is dus (over het algemeen) werk vereist van ons als ontwikkelaars. Bij het Provider Model wordt de binding vastgesteld op basis van de configuratie, waardoor deze eenvoudig veranderd kan worden zonder tussenkomst van een ontwikkelaar. Kort door de bocht is het Provider Model een interface die run-time ingesteld kan worden.

Flexibiliteit… en meer!

Als ontwikkelaar is het werken met een Provider Model API niet veel anders als het werken met een interface. Het biedt ons de flexibiliteit om een andere implementatie te kiezen (of te maken) zonder de code die de interface gebruikt te hoeven veranderen. Dit is het meest gehoorde voordeel dat de voorstanders van het Provider Model noemen. Hoewel dit zeker een voordeel is, laat de overeenkomst met een interface al zien dat er meer technieken zijn waarmee hetzelfde voordeel te halen valt. Dat de te gebruiken implementatie in de configuratie bepaald wordt heeft echter een voordeel waar wij als ontwikkelaars niet vaak bij stil staan: je hoeft niet te kunnen programmeren om te bepalen welke implementatie gebruikt wordt. Als je, met dit gegeven in je achterhoofd, verder kijkt naar hoe het Provider Model toegepast wordt in ASP.NET, zie je dat het verbeterde mogelijkheden biedt om declaratief te kunnen programmeren. Controls als Login, LoginStatus, SiteMapPath, enz. zijn allemaal te gebruiken zonder dat je (diepgaande) programmeerkennis nodig hebt. Voor iemand die alleen bekend is met HTML, zijn het een soort HTML++ elementen die naast opmaak ook functionaliteit bieden. Daarmee gaat het een stap verder in de scheiding tussen ontwerper en ontwikkelaar dan het code behind model, omdat de ontwikkelaar bij het maken van pagina’s eigenlijk helemaal niet meer nodig is. Dat wordt puur het domein van de mensen die verstand hebben van het maken van een goede gebruikersinterface. Aangezien ontwikkelaars daar meestal niet toe in staat zijn is dat eigenlijk ook maar beter ook.

Beperkt toepasbaar

Applicaties maken zonder te hoeven “programmeren” is de heilige graal die we al decennia met 4de generatie talen (4GL) proberen te vinden. We zijn er ondertussen achter dat we een eind kunnen komen, zolang we het domein enorm beperken. Diezelfde beperking geldt in feite ook voor het Provider Model. Het is vrijwel onmogelijk om een API en een verzameling controls te ontwikkelen die in alle situaties de oplossing kunnen bieden. Hoe handig het ASP.NET Membership systeem ook is voor een groot gedeelte van de websites, er zijn altijd applicaties waarin het Membership systeem behoorlijk tekort schiet. Dat komt omdat het Provider Model niet kan voorzien in specialistische oplossingen, het gaat juist uit van de grootst gemene deler. De onderdelen in ASP.NET die werken op basis van het Provider Model bevatten alle de meest voorkomende functionaliteit. Treed je buiten die paden, dan zul je uiteindelijk toch zelf iets moeten bouwen. De kunst is om dat zoveel mogelijk te doen met “aanbouw”, zodat je niet alles over boord hoeft te zetten dat ASP.NET biedt.

Zelf implementeren

Als je je zo min mogelijk wilt bemoeien met het gebruikersinterface, dan kan het handig zijn om functionaliteit volgens het Provider Model op te zetten. Als je eenmaal weet hoe dit moet is de extra moeite die je daarvoor moet doen verwaarloosbaar. Op de MSDN website is een uitstekende uitleg te vinden van Rob Howard over hoe het Provider Model werkt en hoe je het implementeert. Deel 1 kun je vinden op http://msdn.microsoft.com/en-us/library/ms972319.aspx en deel 2 op http://msdn.microsoft.com/en-us/library/ms972370.aspx. Houd er rekening mee dat de uitleg dateert van voor de release van ASP.NET 2.0 en dat classes als ProviderBase inmiddels in het .NET Framework beschikbaar zijn.

Dit artikel is eerder verschenen op de website van SDN, 17-10-2008.