Sembra un concetto banale, ma per i novizi queste domande possono creare una miriade di dubbi:

- Quando devo abilitare o disabilitare il viewstate? Me ne devo preoccupare?
- Ma quando devo mettere il <form runat="server">...</form>

Parlo per esperienza personale, qualsiasi critica costruttiva è accettata, le altre le mando a quel paese. Il viewstate dev'essere sempre disabilitato se non dove è necessario! Una regola che io seguo è inserire nel web.config della web.application la sua disabilitazione:

<configuration>
 <system.web>
  <pages
   enableViewState="false"
  />
 </system.web>
</configuration>

Quindi, nelle pagine in cui serve:

<%@ Page enableViewState="true" %>

Ma quando serve abilitare il viewstate? Personalmente penso che sia necessario il viewstate solo nei form dove sono presenti webcontrol popolati con il DataBind da una fonte dati come dropdownlist, listbox e simili (se questi web control sono popolati da codice, possiamo disabilitare tranquillamente il viewstate), altrimenti il suo uso è inutile e addirittura dannoso visto che appesantisce, e in molti casi notevolmente, la pagina.

Ma il viewstate può essere pericoloso anche quando non ce ne accorgiamo. Come il più subdolo e temibile nemico, esso può insidiarsi nel nostro codice e passare inosservato allo sguardo dei novizi. Ipitizziamo di scrivere questo semplice codice:

<%@ Page language="c#" %>
<script runat="server">
void Page_Load()
{
 for (int i=0;i<1000;i++)
  testo.Text+="az";
}
</script>
<form runat="server">
<asp:label id="testo" runat="server" />
</form>

Esso non fa altro che inserire una stringa di media lunghezza in una label. Niente di strano, vero? Eppure se si esamina il codice html ci accorigamo che il viewstate, non solo come un nemico, ma operando come un virus, un trojan, un bastardo qualsiasi, ha inserito un sacco di codice in più inutilmente:

<form name="_ctl0" method="post" action="test_label.aspx" id="_ctl0">
<input type="hidden" name="__VIEWSTATE" value="dDwxNTI2NjQ5NzQ0O3Q8O2w8aTwwPjs+O2w8dDw7bDHQ7PjtsPGF6YXphemF

6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YX
phemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphe
mF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6YXphemF6
YXphemF6Y..."

La pagina, invece di avere una dimensione di 2026 bytes, è passata a 4951!!! Questo è dovuto dal Framework che inserisce anche il contenuto del web control Label all'interno del viewstate, comodo in caso di postback per non reinserire ogni volta il testo all'interno della label; ma il problema qui è soprattutto dal complice form elaborato dal server. Se avessimo scritto più semplicemente:

<%@ Page language="c#" %>
<script runat="server">
void Page_Load()
{
 for (int i=0;i<1000;i++)
  testo.Text+="az";
}
</script>
<asp:label id="testo" runat="server" />

Otterremo il codice compatto voluto. Purtroppo questo tipo di form è necessario in presenza di webcontrol che effettuano il postback come i Button, LinkButton, webcontrol vari che permettono l'autoPostBack, DataGrid e così via... Su quest'ultimo webcontrol mi voglio soffermare. Il DataGrid è comodissimo, e tra le comodità che esso permette c'è la paginazione automatica che personalmente ritengo un'infamia all'ottimizzazione del codice. Per il cambio di pagina è necessario trasferire ogni volta un sacco di dati inutili (e l'ottimizzazione del trasporto di questi dati non è semplice) compromettendo prestazioni e banda disponibile al server, e non è possibile disabilitare il viewstate altrimenti non funziona più nulla. Dico io: - E' così difficile creare dei semplici link tradizionali con il passaggio del numero di pagina da visualizzare in questo modo?

<a href="pagina.aspx?pagina=1">Pagina 1</a>
<a href="pagina.aspx?pagina=2">Pagina 2</a>
...

Quindi, quando ripopoliamo il datagrid, è sufficiente riprendere questo dato per visualizzare la pagina desiderata:

DataGrid1.DataSource=ds;
DataGrid1.CurrentPageIndex=Convert.ToInt32(Request.QueryString["pagina"]);
DataGrid1.DataBind();

Sì, lo ammetto, per altri compiti il datagrid è comodissimo come la modalità edit e così via, ma anche qui le migliorie da implementare non sarebbero poche. Ma per favore, basta le oscenià di postback per fare un semplice Redirect di pagina.

Dunque, giunti a questo punto, possiamo enunciare delle piccole regole di base:

1. Disabilitare sempre il viewstate dal web.config
2. Controllare se nel nostro codice è necessario quell'infame del viewstate controllando la presenza di webcontrol popolati con il DataBind.
3. Verificare la necessità di inserire il form elaborato dal server (<form runat="server">...</form>). Solitamente questo è necessario solo con oggetti che possono effettuare il postback.
4. Verificare se la stessa procedura che otteniamo con il postback sia possibile anche con link o con form tradizionali (si veda l'esempio del datagrid paginato).

Infine sarebbe buona regola non mangiare pesante prima di andare a letto, altrimenti vengono fuori blog come questi.