Provider Model Design Pattern

Sentirete spesso parlare del Provider Model Design Pattern (PMDP). Per chi sa già cosa sono i pattern, è essenzialmente una rielaborazione del Pattern Strategy.

In pratica, il concetto che sta alla base di questo pattern è il seguente: si procede con la definizione di una famiglia di algoritmi, incapsulando le implementazioni concrete di ciascuno di essi in un oggetto, rendendoli intercambiabili tra di loro.

L'uso congiunto del Pattern Abstract Factory consente di disaccoppiare l'implementazione concreta rispetto all'oggetto factory, che è ciò che viene utilizzato esternamente nel nostro codice. Questo approccio consente di cambiare l'implementazione concreta senza che l'oggetto factory debba subire grossi cambiamenti, perché ciò che varia è la strategia contenuta all'interno dell'implementazione.

Il vantaggio immediato che comporta è quello di rendere possibile la variazione dell'implementazione concreta senza dover modificare l'oggetto factory.

In parole povere, cambiando l'implementazione concreta non è necessario cambiare nient'altro, dato che l'oggetto che incapsula la strategia fa riferimento all'implementazione vera e propria, mentre l'applicazione utilizza un tipo astratto da cui derivano le diverse specializzazioni.

Tornando al PMDP, il tutto si traduce essenzialmente in questo semplice concetto: fare in modo che alcune funzionalità siano esposte attraverso una classe "pubblica", che prende il nome di API, che però in realtà effettua le operazioni utilizzando le classi provider, ovvero quelle che nello Strategy Pattern implementano gli oggetti concreti.

Il vantaggio più grande di questo approccio è quello di rendere possibile la creazione di nuove funzionalità completamente code-less, dato che le API, per loro stessa natura, garantiscono di essere fisse e di non cambiare e dunque ci possono essere web controls, come vedremo in questa serie di articoli, che sono in grado di richiamare sempre queste API "pubbliche", che però a loro volta si basano sull'implementazione concreta del provider per fornire funzionalità specifiche.

All'interno di ASP.NET 2.0 il PMDP è implementato in maniera specifica nei nuovi building blocks, ovvero nelle fondamenta di questa nuova versione.

Sentirete sicuramente parlare, nei prossimi mesi, di Membership, Roles e Profile APIs, dato che sono alla base di quello che le applicazioni web fanno, nel 99% dei casi: fornire un'infrastruttura in grado di rendere davvero semplice la creazione di applicazioni che implementino funzionalità quali la registrazione degli utenti, l'assegnazione di ruoli a questi ultimi e la gestione del profilo di ciascuno di essi.

Bene, grazie a questa nuova implementazione, con ASP.NET 2.0 creare un sistema del genere, completo in ogni sua parte, può richiedere da 2 a 5 righe di codice, a seconda di ciò che si vuole fare, e non più di un'ora scarsa di tempo.

Questo è possibile perché ci sono dei web controls, come accennato, che richiamano alcuni metodi fissi delle classi del .NET Framework, che non cambiano mai. Nel caso del web control CreateUserWizard, che come il nome stesso suggerisce fornisce un wizard per aggiungere nuovi utenti, viene invocato il metodo CreateUser della classe Membership, che proprio perché implementa il PMDP, in realtà demanda il lavoro al provider che abbiamo specificato. Tradotto in un esempio reale, vuol dire che in realtà se volete migrare la vostra piattaforma da un database Oracle ad uno SQL Server tutto quello che dovete cambiare è il provider che state utilizzando, nel web.config, e nemmeno una riga di codice oltre quest'ultima modifica, dato che io ho la garanzia, datami dal concetto stesso di provider, che differiranno per implementazione interna, ma potranno essere usati allo stesso modo dalla classe Membership.

Questo concetto può sembrare, a seconda dello stato d'animo, l'invenzione dell'acqua calda o qualcosa di assurdo. In entrambi i casi basta provare ad utilizzare i nuovi controlli della famiglia Security per capire fino in fondo quanto sia potente questo approccio.

C'è sempre e solo una form per pagina, ma...

La limitazione più grande di ASP.NET è quella che la pagina può avere una sola form, che tra l'altro non può inviare dati ad altre pagine. Questo vuol dire che nel caso di una form che punti ad un motore di ricerca interno è necessario, spesso, ricorrere ad hack o trucchi vari, spesso rinunciando ai vantaggi che un approccio object oriented garantisce. In più, anche se questo problema dovesse essere superato, rimane sempre quello dei validator: il singolo validator scatta a prescindere dal button che causa il PostBack, rendendoli inutilizzabili se nella pagina ce n'è più di uno.

La cattiva notizia in questo senso è che anche con la 2.0 ci può essere solo una webform per pagina. Quella buona è che, comunque, questa limitazione non è più così pesante come nella 1.x, perché ci sono nuove funzionalità.

Una di queste prende il nome di CrossPagePostBack e si traduce essenzialmente in un nuovo attributo aggiunto alla classe Button, chiamato PostBackUrl.

In pratica, basta inserire il button in questo modo sulla pagina:

Ed al click su di esso si verrà automaticamente inviati sulla pagina specificata.

All'interno di quest'ultima, poi, si dovrà sfruttare una nuova classe, PreviousPage, con cui recuperare il controllo, attraverso il metodo FindControl, e dopo averne effettuato il casting poter accedere a tutte le proprietà dello stesso:

In questo modo si continua ad utilizzare, in automatico, le funzionalità dei web controls, sfruttandone appieno le caratteristiche OO ed accedendo alle proprietà dei controlli come se si trovassero sulla stessa pagina.

Sul fronte dei validator controls, invece, per aggirare il problema delle validazioni che scattano alla pressione di qualsiasi pulsante contenuto nella pagina, è stata introdotta una nuova proprietà di nome ValidationGroup, che può essere applicata sia ai validator che ai button (o più in generale, ai controlli che scatenato il PostBack con la pressione da parte dell'utente). Ovviamente se un controllo Button ha questa proprietà farà scattare la validazione solo dei Validator che avranno lo stesso valore.

In più, ora i validators emettono codice cross browser, quindi compatibile anche con Mozilla o Opera.

Contenuti dell'articolo

• Pagina 1
  • Cronaca di una versione di successo
  • Le novità in VS 2005
• Pagina 2
  • La nuova architettura di ASP.NET 2.0
  • Directory speciali
• Pagina 3
  • Provider Model Design Pattern
  • C'è sempre e solo una form per pagina, ma...
• Pagina 4
  • Compilation Model, precompilazione e nocompile mode
  • Dove scaricare il runtime e l'SDK
  • Conclusioni
  • Tutti gli articoli dello speciale su ASP.NET 2.0