Le sessioni in ASP.NET MVC sono uno degli strumenti più usati… e allo stesso tempo più abusati.
Molti progetti iniziano con qualche valore in Session, poi crescono, si stratificano, e alla fine nessuno sa più cosa contiene davvero la sessione né quando viene svuotata.

Il risultato è quasi sempre lo stesso:

1. bug difficili da riprodurre
2. comportamenti diversi tra utenti
3. problemi di scalabilità
4. performance degradate

Vediamo quindi quando la Session è uno strumento corretto e quando invece è una cattiva scelta architetturale.

Cos’è davvero la Session (e cosa NON è)

La Session è uno spazio di memoria associato all’utente, mantenuto tra una richiesta HTTP e l’altra.

Caratteristiche fondamentali:

• è server-side
• è identificata da un SessionID (cookie o URL)
• non è persistente
• può scadere o andare persa

Inoltre (!):

• La Session non è un database,
• non è affidabile a lungo termine,
• non è pensata per contenere logica di business.

Quando usare la Session (casi legittimi)

Ci sono scenari in cui la Session è assolutamente sensata.

1. Wizard e flussi multi-step

Esempio:

• questionari, 
• form a più pagine
• procedure guidate

Stato temporaneo, legato alla navigazione corrente.

2. Dati non persistenti ma costosi da ricalcolare

• filtri complessi
• configurazioni temporanee
• risultati intermedi

Se il dato non deve essere salvato, ma è costoso da ricostruire.

3. Flag di stato dell’utente

• step completati 
• warning già mostrati 
• messaggi one-shot

Piccoli boolean o valori semplici.

Quando NON usare la Session (errori comuni)

Qui iniziano i problemi seri.

❌ Salvare oggetti complessi o entità di dominio

Session("Domanda") = domanda
Session("ListaUtenti") = listaUtenti

Problemi:

• serializzazione implicita
• dati non sincronizzati col DB
• stato non prevedibile
• memory leak sotto carico

Mai salvare modelli di dominio in Session.

❌ Usare la Session come database temporaneo

Tipico errore:

“Intanto lo metto in Session, poi vediamo”

Conseguenze:

• perdita dati
• utenti che “tornano indietro”
• sessioni scadute senza controllo

Se il dato conta, va nel database.

❌ Dipendere dalla Session per la logica applicativa

If Session("IsAdmin") = True Then
    ' logica critica
End If

Questo è un errore architetturale grave.

• la sessione può essere persa
• il flusso diventa non deterministico
• impossibile scalare correttamente

L’autorizzazione non vive in Session.

Impatto sulle performance e sulla scalabilità

Le sessioni non sono gratis.

Session InProc

• usa memoria del web server
• veloce
• non scalabile
• riavvio = perdita sessioni

Session State Server / SQL Server

• più affidabile
• più lento
• serializzazione obbligatoria
• I/O aggiuntivo

In ambienti ad alto traffico, la Session diventa un collo di bottiglia.

Session e Web Farm: il problema nascosto

Se hai più server:

• Session InProc => non funziona
• Load balancer => sessione persa
• Sticky session => scalabilità limitata

👉 Se non sai rispondere alla domanda
“cosa succede alla sessione se il server cade?”
allora stai già correndo un rischio.

Alternative migliori alla Session

✔️ Database

Per dati:

• importanti
• persistenti
• condivisi
• auditabili

✔️ Cache (MemoryCache / Redis)

Per dati:

• temporanei
• ricalcolabili
• condivisi
• ad accesso frequente

✔️ Hidden field / ViewModel

Per dati:

• limitati alla singola view
• trasmessi esplicitamente
• sotto controllo

✔️ Token e Claims

Per:

• autorizzazioni
• ruoli
• contesto utente

Regole d’oro 

1. Se il dato è fondamentale, non va in Session.
2. Se il dato serve a lungo, non va in Session.
3. Se il dato guida la logica, non va in Session.

La Session è un supporto temporaneo di navigazione, non una scorciatoia architetturale.

Conclusione

La Session non è il male assoluto, ma va usata con criterio.
Nella maggior parte dei progetti problematici che ho visto, la Session era:

• troppo piena
• troppo centrale
• troppo poco controllata

Usata bene semplifica.
Usata male complica tutto.