Grazie a questa classe finalmente non serve piu portarsi in giro i valori in questo modo, facendo continuamente una serie di cast, dato che la Session non si puo? tipizzare perche? generica.
Dal punto di vista tecnico se guardiamo la classe Profile una classe che eredita dalla classe System.Web.Configuration.ProfileCommon che estende ProfileBase e viene creata al volo dal Framework infatti se si va a vedere usando il ?vai a definizione? si viene diretti ad un file temporaneo di ASP.NET. Ma questo non ha molta importanza adesso, molto più importante è invece il fatto che sia direttamente configurabile da web.config.
Infatti per quanto riguarda un utilizzo immediato, che spesso è piu che sufficiente, l?unica cosa che si deve fare è aprire il tag profile in questo file (sempre piu' ricco di versione in versione ;-) e definirne le proprieta' come in questo esempio:



N.B. E' possibile che la versione di Visual Studio .NET che state utilizzando vi segnali degli warning sui Tag. Questo perchè è ancora in fase di Beta. La versione definitiva non dovrebbe presentare questo problema.

A questo punto è direttamente il motore di ASP.NET che ci rende disponibili questi valori per tutto il tempo della sessione. Da ora in poi bastera? gestire in lettura e scrittura le proprieta? a "livello di intellisense" nelle varie pagine dell?applicazione:



Che tipi di dati posso usare nel definire il mio "profilo utente"?
Sono ovviamente supportati tutti i tipi del Framework, ma si possono definire anche delle strutture direttamente a livello di config, o ancora piu interessante, tipi di oggetti che definiamo noi internamente o esternamente all?applicazione, l'importante è che si specifichi eventualmente il namespace dove si trova la classe (e quindi la dll sia sotto alla directory bin).
Nell'esempio precedente il tipo "indirizzo" è definito direttamente nel web.config mentre "Permessi" è 1a classe dell'applicazione definita nel file sotto la directory speciale "app_code" dove vanno le classi comuni come in figura:



A proposito di directory speciali, quando si utilizza il tag "profile" senza specificarne ulteriori attributi (quindi usando le predefinite di visual studio 2005) i file di database utilizzati dal motore vengono parcheggiati nella cartella "app_data" (nella BETA 1 in formato Access 2000 si chiama "aspnetdb.mdb" , dalla BETA 2 diventato SQL Express quindi ".mdf" dato che quest'ultimo permette di linkare un file di database "al volo").
Questo motore gestisce di default anche le altre caratteristiche come "Membership" o lo stato delle "Webparts" (come le visualizzazioni o le disposizioni delle varie zone all'interno delle pagine) e il tutto viene reso disponibile di default all'accesso successivo, senza preoccuparsi di salvare e caricarle.
Ovviamente si puo' decidere di modificarle o ripristinarle quando si desidera, senza preoccupazioni per ciò che riguarda il salvataggio in quanto si preoccupera' di tutto il Framework.

Come vengono memorizzati i dati?
La struttura del database è questa:



Ovviamente i link sono per ApplicationId e per userID ;-) ed internamente si arrangia lui a memorizzarli con dei caratteri separatori per lo schema e a serializzare in XML i valori come appare qui :



Tutto questo viene fatto e gestito dal Framework che integra il suo provider dedicato, e quindi lo sviluppatore si preoccupa solo di maneggiarne i valori.


Memorizzare le informazioni in un Database diverso da SQL Express
Di questo non c'e' da preoccuparsi perche' se non si vuole utilizzare il provider di deafult (nella BETA 1 è Access 2000 e SQL Express nella BETA 2) bensi altre basi dati dove memorizzare questi dati, bastera' farselo a mano facendo l'override di alcuni metodi come Initialize(), SetPropertyValues() ecc. spiegato nella documentazione MSDN
e specificare nel web.config all'interno del tag profile, l'attributo "defaultProvider" con il nome della classe e definirne all'interno il provider che probabilmente avra' bisogno di specificare anche la connectionString della base dati come in figura:



L'esempio sopra utilizza un database Access che era quello di default nella BETA 1 di Visual Studio 2005 che invece di dilettarsi a crearselo personalizzato si puo' tranquillamente scaricare ed utilizzare quello che viene dato da Microsoft stessa come starter-kit qui:

http://lab.msdn.microsoft.com/vs2005/downloads/starterkits/ ">Lab MSDN (ultimo esempio in baso)

Un link veramente consigliato ;-)

Un'ultima cosa da dire è che è possibile creare un profile anche per gli utenti anonimi, definendo all'interno delle proprietà l'attributo allowAnonymous="true", e addirittura è possibile specificare quale sara' il tipo di serializzazione che si vuole usare con il serializeAs="String" o serializeAs="Xml".

PRO:
- Svolge splendidamente il suo lavoro, permette di essere scalabili e facilmente espandibili.
- I valori sono disponibili automaticamente all'accesso dello stesso utente mentre la Session va riempita a mano.
- E? una classe con i valori tipizzati al contrario della Session che richiedeva dei cast.

CONTRO:
- Viene svolto un ottimo lavoro "dietro le quinte" ma l'implementazione di un provider personalizzato è laboriosa.