Quando si sviluppa un'applicazione, uno dei requisiti principali da tenere in mente è la scalabilità del sistema. Questo requisito diventa un "MUST" quando si parla di applicazioni web che possono risiedere su più server, poichè ci sono diversei aspetti da tenere in considerazione.
Innanzitutto la sessione. Anche se l'infrastruttura di asp.net ci viene incontro dandoci la possibilità di impostare uno store unico (SqlServer, o una macchina che funge da StateServer), bisogna sempre tenere in mente che questi oggetti devono essere serializzabili per poter essere spediti attraverso la rete. In caso si vogliano memorizzare classi scritte da noi il problema non si pone, basta utilizzare l'attributo Serializable e il problema è risolto. Ma cosa se si devono memorizzare classi scritte da terze parti che non possono essere serializzate?? Per scoprire la cosa sul nascere, ho preso l'abitudine di modificare il web.config delle mie applicazioni (ovviamente solo in fase di sviluppo) impostando la modalità di memorizzazione delle sessioni su StateServer e la mia macchina come Host. Ovviamente il servizio dello stato di ASP.NET l'ho messo in startup automatico.
Un secondo aspetto è la sincronizzazione della cache. Quando l'applicazione risiede su un server, il problema non si pone in quanto si può invalidare la cache programmaticamente con un bel Cache.Remove("Item"). In una Web Farm questo non è possibile poichè, così facendo, si azzera la cache solo della macchina su cui si esegue il Remove lasciando le altre con dati obsoleti. Il metodo più semplice (anche se nasconde alcune insidie di sincronizzazione) e quello di impostare una dipendenza tra l'oggetto in cache e un file a cui tutte le macchine puntano. Modificando il file, gli elementi vengono rimossi su tutte le macchine. Come detto sopra, ci sono alcune insidie di sincronizzazione, poichè gli accessi al file devono essere serializzati. Quando si ha a che fare con dati in cache provenienti dal DB, questa soluzione può essere buona, ma si può anche pollare ogni tot secondi il DB per sapere se qualche tabella è stata modificata. A questo punto si entra nelle correnti di pensiero. Alcuni sostengono che eseguire una query ogni n secondi, che la maggior parte delle volte tornerà "Dati non cambiati", sia solo un'inutile spreco di risorse quindi vada modificata solo dai thread delle pagine quando se ne ha bisogno. Altri sostengono che la cache debba essere caricata e scaricata in background in modo da non bloccare i thread delle pagine. Personalmente credo che creare un trigger, in ascolto sulle tabelle da sincronizzare, che modifichi il file tramite una stored procedure estesa sia un metodo abbastanza semplice ed efficace. (Sono pronto per ogni smentita ;). Tutto questo ovviamente non varrà con ASP.NET 2.0 grazie alla SqlCacheDependency
Rimane il discorso delle variabili di applicazione, ma ormai le ho soppiantate usando attributi statici nel Global.asax. Questi contengono i valori del web.config in modo da renderli disponibili già tipizzati.

Vabbè, vado a correre che è meglio va... siamo in piena lotta per la salvezza.