Nello sviluppo di applicazioni per il web, il Caching di solito viene applicato alle informazioni provenienti da un database. A tal proposito l'ASP tradizionale offre pochissimo supporto. Una delle tecniche più utilizzate dagli sviluppatori ASP per mettere in Cache, ad esempio, il risultato di una query ad un database è l'utilizzo delle variabili Application, con tutti i problemi che esse comportano (pensiamo ad esempio al Lock dell'oggetto Application).
Con ASP.NET la situazione è cambiata notevolmente. Infatti il Framework .NET mette a disposizione una serie di classi sviluppate ad hoc che permettono di gestire in maniera molto semplice ed efficace tutto quello che riguarda il Caching. ASP.NET prevede diversi meccanismi di caching al suo interno. Alcuni meccanismi sono interni al Framework .NET (ed ovviamente al CLR) ed automatici (quindi trasparenti per lo sviluppatore). Si tratta dei cosiddetti internals del Framework .NET. A tal proposito distinguamo:

• Caching delle pagine;
• Caching della configurazione.

Altri, invece, devono essere necessariamente abilitati dallo sviluppatore per poter essere utilizzati. In questo caso abbiamo:

• Caching dell'output;
• Caching frammentato;
• Caching dei dati (o Caching programmatico).

Questo meccanismo riguarda essenzialmente la compilazione (e la ricompilazione) delle pagine ASPX. Cosa succede quando una pagina ASPX viene richiesta? Se la pagina viene richiesta per la prima volta, il CLR (Common Language Runtime) compila "al volo" la pagina e la salva in un oggetto temporaneo (assembly) su disco. A questo punto l'assembly viene eseguito in memoria. Alle successive richieste verrà eseguita la versione della pagina in memoria. Se la pagina venisse modificata e in memoria fosse presente una "vecchia" versione della pagina, il CLR "invalida" la pagina in memoria e procede con la ricompilazione delle nuova versione della pagina. Questo meccanismo di Caching spiega anche il perchè della lentezza di risposta del server alla prima richiesta di ogni pagina ASPX. Tutto questo è possibile grazie alla classe FileSystemWatcher di cui si avvale il Framework .NET per monitorare le eventuali modifiche eseguite ai sorgenti dell'applicazione Web.

Per il Caching della configurazione vale lo stesso discorso fatto per il Caching delle pagine ASPX. In questo caso, però, il ciclo parte la prima volta che un'applicazione web viene eseguita, ovvero, la prima volta che una qualunque pagina ASPX viene richiesta in una directory virtuale. Anche il web.config viene monitorato costantemente con l'ausilio del FileSystemWatcher ed eventuali modifiche al file determinano l'invalidazione della Cache e la ricompilazione del file modificato.

Il caching dell'output non è un meccanismo automatico, ma deve essere abilitato esplicitamente (attraverso opportuna direttiva) dallo sviluppatore. Con questo meccanismo è possibile mettere in Cache l'output HTML generato dalle pagine ASPX o, come vedremo in seguito, dai controlli utente. Il Caching dell'output è molto utile quando si hanno delle pagine ASPX "statiche", vale a dire quando si è certi che il contenuto della pagina ASPX non cambierà mai o cambierà molto poco frequentemente.
Abilitare la cache per l'output è molto semplice. Tutto quello che serve è abilitare la direttiva "OutputCache" nella pagina ASPX nel modo seguente:

<%@ Page Language="VB"%>
<%@ OutputCache Duration="60" VaryByParam="none"%>

La direttiva OutputCache prevede diversi attributi. I più comunemente utilizzati sono:

• Duration: esprime per quanto tempo, in secondi, la pagina (o il controllo utente) devono rimanare in Cache. Questo parametro è obbligatorio per le pagine ASPX e per i controlli utente.
• VaryByParam: permette di specificare una lista di stringhe separate da punto e virgola (;). Tale lista serve ad ASP.NET per "capire" come e quando variare il contenuto della Cache di output. Queste stringhe corrispondono infatti ai paramatri inviati alla pagina tramite metodo GET o POST.
  Se non si desidera specificare un parametro per variare il contenuto memorizzato nella cache, impostare il l'attributo su "none" (VaryByParam="none"). Se si desidera variare la cache di output per tutti i valori dei parametri, impostare l'attributo su "*" (VaryByParam="*"). Se si desidera variare la cache di output in base ad alcuni parametri, impostare l'attributo in VaryByParam="parametro1;parametro2;parametro3".
  Questo attributo è obbligatorio per le pagine ASPX e per i controlli utente.
• VaryByHeader: funziona come l'attributo VaryByParam, ma considera le intestazioni HTTP anzichè i valori della stringa di ricerca.
• Location: questo attributo è opzionale e non è supportato dai controlli utente. Serve ad indicare dove deve essere memorizzata la Cache. L'attributo può essere impostato su uno dei seguenti valori:
  1. Any (valore di default): l'output può essere messo in cache in una qualunque delle locazioni qui elencate;
  2. Client: la cache dell'output si trova sul client dove è situato il browser che ha eseguito la richiesta;
  3. Downstream: la cache sarà immagazzinata "in fondo" al server dove è stata originariamente processata la richiesta. Viene utilizzato in presenza di proxy server;
  4. None: il caching dell'output non è abilitato;
  5. Server: la cache è posizionata sul server che ha processato la richiesta.

Seguono alcuni esempi di utilizzo della direttiva OutputCache e dei suoi attributi, per meglio comprendere il suo funzionamento.

<%@ Page Language="VB"%>
<%@ OutputCache Duration="60" VaryByParam="none"%>

Con questa direttiva diciamo ad ASP.NET di inserire in Cache per 60 secondi (Duration="60") solo una "versione" di questa pagina. Per 60 secondi, quindi, l'output di questa pagina rimarrà invariato, qualsiasi cosa succeda.

<%@ Page Language="VB"%>
<%@ OutputCache Duration="120" VaryByParam="cognome;nome"%>

Con questa direttiva diciamo ad ASP.NET che ciascuna richiesta HTTP (GET o POST) che arriva con un parametro "cognome" o "nome" (o entrambi) diverso deve essere memorizzata nella cache per 120 secondi. Le richieste successive con gli stessi valori dei parametri verrano prelevate dalla Cache fino alla scadenza.

<%@ Page Language="VB"%>
<%@ OutputCache Duration="120" VaryByParam="browser"%>

Questa tecnica potrebbe essere utilizzata quando lo sviluppatore deve visualizzare diverse versioni di una pagina in base al browser richiedente. Per migliorare la performance potrebbe metterle in Cache sfruttando l'attributo "VaryByCustom".

La direttiva "OutputCache" può essere utilizzata anche nei controlli utente. L'abilitazione del caching nei controlli si ottiene nel modo seguente:

<%@ Control Language="VB"%>
<%@ OutputCache Duration="60" VaryByParam="none"%>

Questa tecnica è molto utile quando si vuole sfruttare il caching dell'output solo per alcuni dati di una pagina ASPX.
Consideriamo il caso di una pagina che visualizza in testa la data e l'ora corrente e al centro una lista di prodotti. Se venisse abilitato il caching per l'intera pagina, data e ora non verrebbero visualizzate in maniera corretta. Per risolvere il problema si potrebbe spostare la lista dei prodotti in un controllo utente ed abilitare solo qui la direttiva OutputCache, lasciando invece nella pagina ASPX la logica per la visualizzazione della data e dell'ora.
E' bene qui ricordare che il tentativo di maneggiare un controllo in cache dal codice della pagina ASPX che lo contiene genererà un errore. Ad esempio il seguente codice non è assolutamente corretto, se per il controllo è stata abilitata la direttiva "OutputCache":

<Acme:TestControl ProprietaXXX='<%# Container.DataItem("Prodotto") %>' runat="server" />

Questo accade perchè il controllo viene creato solo alla prima richiesta; alle successive richieste il controllo non sarà più disponibile e tutti i tentativi di accesso alle sue proprità e metodi falliranno miseramente. Per evitare questo problema, la logica di creazione del controllo dovrebbe essere inserita all'interno degli eventi Page_Load o Page_PreRender del controllo stesso.