Considerando il caso di implementazione più comune (come nel caso della API Membership), il getter della proprietà restituisce l'istanza attivata durante l'operazione di inizializzazione dell'oggetto Manager. Il metodo privato Initialize() invocato nel getter recupera la configurazione tramite il metodo GetAppConfig() della classe statica System.Web.Configuration.RuntimeConfig e procede con l'attivazione del tipo concreto di Provider in base ai settaggi ottenuti. La creazione dell'istanza del Provider è demandata alla classe statica ProvidersHelper, che a sua volta richiama in modo indiretto il metodo Activator.CreateInstance(Type) e il metodo di inizializzazione di ConcreteProvider (vedi diagramma di sequenza).

Dato che la classe che funge da Manager memorizza il suo stato e lo persiste tra le diverse chiamate, l'inizializzazione viene eseguita solamente la prima volta che la proprietà Provider viene utilizzata. Questa operazione è del tutto trasparente, dato che la chiamata del metodo Initialize() è incapsulata nell'ambito del getter della proprietà Provider. Le operazioni di recupero della configurazione e attivazione dell'istanza vengono eseguite nell'ambito di un blocco lock al fine di garantire la thread-safety.

La classe che funge da Manager rimappa le chiamate ai metodi della sua interfaccia su quelli dell'oggetto a cui riferisce la proprietà Provider, eseguendo il codice relativo al Provider caricato a runtime. L'esempio seguente mostra quale sia il codice contenuto nel metodo di cancellazione di un utente della classe Membership. Come si può vedere, il metodo DeleteUser(string, bool) non fa altro che eseguire il metodo corrispondente di Provider e ritornare il risultato dell'operazione.

 public static bool DeleteUser(string username, bool deleteAllRelatedData)
 {
   SecUtility.CheckParameter(ref username,true,true,true,0,"username");
   return Membership.Provider.DeleteUser(username, deleteAllRelatedData);
 }
 

Occorre fare una precisazione. Non tutti i Provider di ASP.NET 2.0 seguono in modo rigido lo schema illustrato finora. Tralasciando, come detto, i BuildProvider e i VirtualPathProvider, in taluni casi, nonostante il funzionamento rimanga concettualmente invariato (Strategy e Dependency Injection), l'implementazione e, in particolare, l'inizializzazione e l'attivazione dell'istanza possono avvenire secondo modalità diverse in base al tipo di API. Per esempio, l'implementazione nel caso dell'API HealthMonitoring è molto complessa e utilizza tipi annidati e un intreccio alquanto complesso di relazioni tra le classi coinvolte. Anche nel caso di SessionState vale un discorso analogo: in questo caso la classe che funge da Manager è addirittura il modulo HTTP relativo alla gestione della sessione (che non è una classe statica). Queste diversità testimoniano la grande adattabilità implementativa che caratterizza il modello e che lo rende applicabile in scenari anche molto diversi tra di loro.

Chiariti i principi che regolano il funzionamento del Provider Model in ASP.NET 2.0, occorre spendere un paio di parole su come le impostazioni vengono inserite nel file di configurazione di una applicazione web. Nell'ambito del machine.config o del web.config a ciascuna API corrisponde una sezione di configurazione, nella quale sono elencati i Provider disponibili e viene definito il Provider predefinito. Ciascun Provider è contrassegnato da un nome che lo identifica univocamente, dal tipo generalmente indicato con il riferimento completamente qualificato e da una serie di altre impostazioni specifiche per l'API in questione. Le impostazioni riguardanti i Provider relativi alle API di ASP.NET 2.0 sono elencate nel file di configurazione di sistema, il machine.config, ma possono essere sostituite con diverse impostazioni nell'ambito del web.config di ciascuna applicazione web. Per esempio, le impostazioni relative al profilo utente presenti nel file di configurazione sono incluse nel nodo <profile />.

 <profile>
     <providers>
         <add name="AspNetSqlProfileProvider"
             connectionStringName="LocalSqlServer"
             applicationName="/"
             type="System.Web.Profile.SqlProfileProvider, System.Web,
             Version=2.0.0.0, Culture=neutral,
             PublicKeyToken=b03f5f7f11d50a3a" />
     </providers>
 </profile>
 

Come è possibile notare nell'esempio, tramite il nodo <add /> è possibile definire uno o più Provider nell'ambito della sezione di configurazione di una particolare API. L'elenco dei Provider disponibili per un'API viene recuperato tramite il metodo GetAppConfig() visto in precedenza e viene salvato in una collezione di tipo System.Configuration.Provider.ProviderCollection. La classe che funge da Manager espone questa collezione tramite la proprietà statica Providers (esempio: Membership.Providers). L'attributo defaultProvider del nodo radice della sezione di configurazione dell'API identifica quale è il Provider concreto da caricare durante l'operazione di Dependency Injection.

 <profile defaultProvider="Provider2">
     <providers>
         <add name="Provider1" type="..." />
         <add name="Provider2" type="..." />
         <add name="Provider3" type="..." />
     </providers>
 </profile>
 

Contenuti dell'articolo

• Pagina 1
  • Motivazioni del Provider Model
  • Il pattern Strategy
• Pagina 2
  • Il pattern Plugin
  • Il pattern Provider utilizzato in ASP.NET 2.0
• Pagina 4
  • Conclusioni

• I nuovi controlli di ASP.NET 3.5: LinqDataSource, ListView e DataPager
• Galleria fotografica dinamica con ASP.NET AJAX
• Usare Search come un servizio nei tuoi siti e nei tuoi client
• Mappe nel tuo sito con Virtual Earth
• Integrare Windows Live ID, Contacts e Presence API nelle tue applicazioni
• Introduzione ai cloud based service con Windows Live Services
• Realizzare un custom extender AJAX con ASP.NET 3.5
• Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008