Questo articolo è tratto dal capitolo 18 (La gestione dello stato) del libro ASP.NET 3.5 per tutti di Daniele Bochicchio, Cristian Civera, Riccardo Golia e Stefano Mostarda.

Acquista subito la tua copia ad un prezzo vantaggioso!

Il colloquio tra client e server è possibile perché esiste uno standard di comunicazione, che è il protocollo HTTP. La sua analisi esula dagli scopi di questo articolo, ma è ad ogni modo fondamentale trattarne la caratteristica più importante per quanto riguarda lo sviluppatore web, cioè la sua natura stateless.

L'essere stateless significa che ogni richiesta che il browser invia è processata dal server in maniera completamente incorrelata e indipendente dalle precedenti, senza lasciare traccia in quelle successive.

Se a prima vista questa può sembrare una limitazione insormontabile, deve comunque essere possibile gestire lo stato, anche se il protocollo in origine non prevede (e continua a non prevedere) un supporto specifico.

Nel corso degli anni lo sviluppo del web ha comportato l'evoluzione delle opportunità che questa piattaforma offre. Quello che una volta era semplicemente un insieme di pagine, adesso è una vera e propria applicazione, con la necessità di dover collegare logicamente tra di loro le pagine visitate da un utente.

A partire dalla versione 2.0 ASP.NET introduce diverse tecniche per gestire lo stato ed all'interno di questo articolo vengono affrontate le tematiche relative a queste funzionalità.

Come funziona una richiesta HTTP

Prendendo come esempio una normale richiesta, il browser invoca la pagina sul server, su questo viene creato il contesto all'interno del quale il processo è eseguito ed infine il server invia il risultato al browser distruggendo il contesto ed eliminando ogni riferimento alla richiesta appena elaborata. Questo meccanismo fa sì che il web sia molto semplice e snello, poiché i server hanno un carico minore, non dovendo mantenere connessioni aperte con i client una volta che questi hanno ricevuto il risultato.

Per capire bene la differenza tra un protocollo stateless ed uno statefull, è bene dare una dimostrazione anche del secondo. L'esempio più classico è quello di una transazione sul database: in questo scenario si aprono connessione e transazione, si lanciano le query di aggiornamento ed infine si chiude il colloquio. Durante tutto il tempo il database ed il client sono sempre connessi ed è per questo che si parla di protocollo statefull.

Da un lato HTTP garantisce performance ottimali, scalabilità ed alta disponibilità, ma dall'altro rende più difficile lo sviluppo poiché ad ogni richiesta si deve ripartire da zero. Per questo motivo è necessario avere a disposizione una serie di meccanismi per recuperare e salvare le informazioni necessarie al funzionamento dell'applicazione come, per esempio, il nome dell'utente. L'insieme delle problematiche e delle tecniche di persistenza dei dati attraverso le richieste prende il nome di gestione dello stato.

Scenari di gestione dello stato

Esistono diverse tecniche a disposizione dello sviluppatore per memorizzare informazioni e la scelta tra una o l'altra dipende da molti fattori come la visibilità del dato, la necessità di performance, la sicurezza o la velocità di implementazione.

Ad esempio, se si deve salvare temporaneamente l'importo di una fattura, il dato va mantenuto nella pagina che lo gestisce perché non c'è bisogno che sia visibile altrove. Viceversa, se si deve mantenere il profilo dell'utente per l'intera durata della sessione, non è certo consigliabile utilizzare meccanismi che lo salvano in ogni singola pagina, ma sfruttarne altri che garantiscono maggior semplicità. E ancora, se ci sono molti dati da associare ad una sessione utente, è preferibile salvarli in un punto dove non occupano risorse di banda, ma solo memoria.

Se le informazioni devono essere persistite, la soluzione ideale è memorizzarle in un punto dove poterle facilmente ritrovare in qualunque momento. Tutte queste casistiche sono molto comuni ed è per questo che nel corso dell'articolo vengono analizzati in dettaglio i meccanismi di memorizzazione che soddisfano tutte queste esigenze.

Esistono principalmente due modi per suddividere le tecniche di gestione dello stato: il primo si basa sulla visibilità dei dati, mentre il secondo sul sistema di memorizzazione.

In base alla prima categorizzazione si possono distinguere tre gruppi: i campi hidden, il ViewState ed il ControlState per informazioni che servono su una pagina; il profilo, le sessioni ed i cookie per quelle a livello utente; l'oggetto Application e la cache per contenere i dati condivisi tra tutti gli utenti.

In base alla seconda distinzione si possono individuare due gruppi: i campi hidden, i cookie, il ViewState e il ControlState che sfruttano le capacità di persistenza del client, e le sessioni, il profilo, l'oggetto Application e la cache che memorizzano i dati lato server.

Lo stato con i campi hidden

Il codice HTML offre un primo meccanismo per persistere alcune informazioni sulla pagina: i campi hidden. Questi campi sono presenti nel codice HTML inviato al browser, ma sono invisibili all'utente ed al loro interno si possono inserire informazioni in formato stringa.

<input type="hidden" id="hdnField" runat="server" />

hdnField.Value = "valore";

Quando si vuole impostare o leggere sul server il valore del controllo, basta fare riferimento alla sua proprietà Value. Poiché ad ogni postback questa proprietà viene valorizzata con i valori di post della form HTML, il suo valore è sempre aggiornato anche in scenari dove il ViewState è disabilitato. La potenza dei campi hidden sta nel fatto che possono essere sia letti che scritti anche sul client tramite Javascript.

document.getElementById('hdnField').value = new Date().toString();

L'utilizzo del controllo HtmlInputHidden è l'unica via percorribile nelle versioni 1.x di ASP.NET. Per compatibilità questa possibilità è stata lasciata anche nelle versioni successive, ma è divenuta obsoleta con l'introduzione del controllo HiddenField che non è altro che la controparte per i web control del controllo HtmlInputHidden visto nell'esempio precedente.

<asp:HiddenField id="hdnFieldServer" runat="server" />

hdnFieldServer.Value = "valore";

La figura 1 riporta il codice HTML generato dallo snippet appena visto. Come si può notare, il risultato non cambia: il controllo HiddenField viene renderizzato sul client come un normale campo hidden.

Figura 1 - HTML generato da un campo hidden.

I campi hidden hanno dalla loro parte l'estrema semplicità di implementazione, la generazione di pochissimo codice HTML e la possibilità di accesso ai valori direttamente nel browser utilizzando Javascript. Il codice nella figura 1 mostra però anche la prima limitazione di questa tecnica: i dati sono in chiaro. Finché le informazioni non sono sensibili, come nel caso del nome dell'utente, del libro preferito o della skin predefinita, il problema non è di grave entità. Quando si comincia a parlare di password, di numeri di carte di credito o di importi di fatture, l'utilizzo diventa improponibile, soprattutto se si viaggia su una connessione non protetta tramite SSL.