Questo articolo è tratto dal capitolo 16 (Membership, Roles e Profile API) del libro ASP.NET 2.0 per tutti di Daniele Bochicchio, Cristian Civera, Riccardo Golia e Stefano Mostarda.

Acquista la tua copia col 10% di sconto!

Profile API: gestione del profilo utente

L'ultima delle API analizzate in questo capitolo è quella che consente di gestire un profilo associato all'utente.

Le Profile API servono, infatti, per fare in modo che sia possibile aggiungere informazioni di contorno ad un profilo utente.

Rispetto alla sessione, che ad esempio è utilizzata con la versione 1.x, ha il vantaggio di salvare le proprie informazioni in uno storage persistente, dato che i dati salvati in sessione durano fino a quando esiste la sessione stessa e sono persi in caso di timeout.

Questa situazione è ottimale in alcuni casi, ma a volte si ha l'esigenza di persistere i dati su un database, o su uno storage differente, ed è proprio in questo caso che entrano in gioco le Profile API. Queste consentono di memorizzare i dati direttamente su uno storage persistente, che è stabilito in base al provider che si utilizza.

Anche in questo caso, la prima operazione da eseguire per implementarne il supporto è specificare attraverso il web.config il provider utilizzato.

L'unico distribuito con ASP.NET 2.0 è SqlProfileProvider, contenuto nel namespace System.Web.Security, che è una classe che eredita da quella astratta ProfileProvider, a sua volta basato sempre su ProviderBase.

Il provider per SQL Server sfrutta lo stesso tool che si è visto con le Membership API per la fase di setup ed utilizza una serie di tabelle che rendono possibile la creazione di qualsiasi proprietà all'interno del profilo utente.

La classe Profile esposta all'interno di Page o HttpContext non è nient'altro che una classe, costruita sulla base di ProfileCommon, creata al volo in base alla configurazione delle proprietà.

Una delle possibilità per specificare queste proprietà è quella di sfruttare il web.config, precisamente tramite la sezione properties situata sotto profile, per aggiungere proprietà o gruppi di queste, come nell'esempio 16.12.

<system.web>
  <profile enabled="true" automaticSaveEnabled="true">
    <properties>
      <add name="Skin" />
      <add name="DataUltimoAccesso" allowAnonymous="true"
        type="DateTime" serializeAs="String" />
      <group name="AlbumPreferito">
        <add name="Titolo"/>
        <add name="Autore"/>
        <add name="DataPubblicazione" type="DateTime"/>
        <add name="NumeroCanzoni" type="int"/>
      </group>
    </properties>
  </profile>
</system.web>

L'attributo automaticSaveEnabled è importante perchè specifica se salvare o meno i dati ogni volta che questi vengono modificati. Se la proprietà è impostata su true, il valore di default, ad ogni modifica del profilo corrisponderà una modifica anche nello storage, in caso contrario si dovrà utilizzare il metodo Save della classe Profile.

Il nodo properties, come detto, andrà a contenere le effettive proprietà che saranno aggiunte alla classe creata in automatico alla prima esecuzione. L'accesso a questa classe è tipizzato, per cui ogni elemento add deve avere un attributo name, che identifica il nome del campo, ed uno type, che ne specifica il tipo del CLR e che se omesso è sempre string.

Nell'esempio 16.12, il campo DataUltimoAccesso è stato identificato come tipo DateTime. In fase di salvataggio, questo viene serializzato e l'operazione viene decisa in base alla tipologia di dato, a meno che non venga specificato l'attributo serializeAs, utilizzando uno dei quattro valori ammessi.

Tabella 16.6 - I possibili valori dell'attributo serializeAs

Per organizzare meglio i dati, le proprietà si possono racchiudere in gruppi attraverso l'elemento group, all'interno del quale devono essere inseriti più elementi add.

É importante sottolineare che un gruppo non può contenere un altro gruppo, quindi non si può creare una struttura gerarchica a più livelli. L'unica proprietà necessaria per il nodo group è name, che specifica il nome dello stesso.

Oltre a properties, il nodo profile contiene anche il nodo providers che serve per specificare quali siano i provider utilizzati. Questo nodo contiene tanti elementi add quanti sono i provider installati ed ognuno di questi deve avere una proprietà name, che è quella specificata nell'attributo provider delle proprietà del profilo, quando si decide di suddividerle su più provider e crearne quindi di specifiche per ciascuno di questi.

Il nodo providers non è obbligatorio perchè ereditato, anche in questo caso, dal machine.config, che punta sempre al solito database di SQL Server 2005 Express. Per modificarlo, è sufficiente agire sul web.config, come già fatto in altri casi per gli altri provider, così come mostrato nell'esempio 16.13.

<profile defaultProvider="SqlServerProfile">
  <providers>
    <add
      name="SqlServerProfile"
      type="System.Web.Profile.SqlProfileProvider,
            System.Web, Version=2.0.3600.0,
            Culture=neutral,
            PublicKeyToken=b03f5f7f11d50a3a"
      connectionStringName="SqlServer"
      applicationName="/" />
  </providers>
</profile>

Anche in questo caso, connectionStringName è il riferimento alla stringa di connessione, mentre name è il nome del provider e type il tipo da utilizzare.

Nota
All'interno del materiale allegato a questo libro, tra le demo del capitolo, ce ne sono alcune dedicate in maniera specifica all'utilizzo in maniera combinata di Membership, Roles e Profile API. Nel caso specifico, c'è la possibilità di utilizzare una pagina che invia una newsletter personalizzandola in base ad alcune informazioni contenute sia nel profilo utente che in quello di autenticazione, piuttosto che avere un comodo pannello di gestione degli utenti e dei ruoli ad essi associati.