Provider Model Design Pattern
Mi ci sono imbattuto per la prima volta 2 anni fa, modificando ed assimilando l'architettura del forum. All'inizio mi sembrava un controsenso, un appesantimento del sistema.
A capo del progetto c'è sempre stato Rob Howard, allora PM del dev team di ASP.NET, da un paio di mesi tornato "libero".
La versione 2.0 dei forum, in beta, è in realtà la prima ad implementare anche altri provider, ma già nella 1.0 era possibile vedere, seppure limitatamente a SQL Server, quanto fosse geniale l'idea di avere API generiche e l'implementazione particolare fornita da una classe specifica, specializzata per ogni data provider. Fu così che nacque il Provider Model Design Pattern.
Se ne trova una ampia trattazione in questa prima parte e nella seconda, applicata alle funzionalità di ASP.NET 2.0.
Niente di strano, è un pattern come tanti altri, verrebbe da pensare.
No, in realtà è il pattern per ASP.NET 2.0. Tutte le funzionalità, dall'authorization APIs, alla personalization, ai SiteMap, a qualsiasi cosa vi passi per la testa (inclusi i data controls) passa per questo pattern.
Tutto in ASP.NET è pluggabile, ovvero, tanto per capirci, è arricchibile da plug-in. Che vuol dire, semplicemente, che tutto è comandato da provider.
Sembra tanto, se ci riflettiamo bene, la scoperta dell'acqua calda. Invece è solo la presa di consapevolezza che nel mondo dello sviluppo non siamo soli, che dobbiamo preparci ai cambiamenti (perchè, come sviluppatori lo sappiamo, le esigenze delle nostre applicazioni variano spesso) e che dobbiamo, soprattutto, incominciare ad utilizzare regole, precise e rigorose, per le parti sensibili delle nostre applicazioni.
Il vantaggio di un modello rispetto ad un'implementazione astratta, poi, è che chi lo implementa non deve subire scelte progettuali specifiche, perchè, in fin dei conti, è libero di fare ciò che vuole, a patto che rispetti poche ma sensate regole.
Pensate alle Personaltion APIs: se le avete provate noterete quanto sia semplice personalizzare la propria implementazione.
Alla fine dovremo sempre utilizzare la classe ProviderBase come punto di partenza, piuttosto che le implementazioni particolari, come MembershipProvider, ma ciò che resta è il concetto: essere liberi di creare il proprio provider, non buttare via la struttura attuale delle nostre applicazioni web, ed essere felici di passare alla 2.0 con la consapevolezza che ASP.NET ha raggiunto ormai un ottimo punto di maturazione.
Segnala su: 
Nella stessa categoria
I più letti del mese
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.