Lottando con l'uso accettabile della variabile Session in ASP.NET

Question

Ho cercato di evitarmi di ritirare tutto in una variabile Session in ASP.NET (provenivo da un background di programmazione Windows) e in genere ho completamente smesso di archiviare esplicitamente qualsiasi cosa in una variabile Session. Qualcuno può fornire alcune linee guida su ciò che ritieni siano usi accettabili della variabile di sessione?

Ecco un esempio specifico ... carico un oggetto business dal database e popolo e modifico la schermata. L'utente può modificare i valori e salvare. Alla vecchia maniera avrei caricato l'oggetto business, caricato il mio modulo e salvato l'oggetto business in una variabile di sessione. Se l'utente ha fatto clic su Salva, vorrei recuperare l'oggetto business dalla variabile di sessione, sostituire i valori modificati e quindi salvarlo. Il nuovo modo in cui sto caricando l'oggetto business dal database e carico il mio modulo. L'utente modifica i valori e fa clic su Salva. Vorrei ricaricare il mio oggetto business dal database, sostituire i valori modificati e quindi salvarlo. Non sono un esperto di programmazione Web, ma ritengo che il primo modo sia sbagliato a causa del cattivo stigma dell'uso delle variabili di sessione, e ritengo che il secondo modo sia sbagliato perché sembra solo un modo scadente di farlo (caricare l'oggetto business due volte ). Non prendiamo in considerazione alcuna forma di cache qui. Come lo gestirò?

Answer 1

Non sono affatto offeso ricaricando l'oggetto business dal database sul post per salvare le modifiche degli utenti.

Quell'oggetto deve provenire da qualche parte in quel postback e l'overhead limitato associato a una rapida chiamata DB come prendere un oggetto specifico è probabilmente la soluzione migliore.

Le tue opzioni per riportare in memoria quell'oggetto business sul post back:

• Ricevilo di nuovo dal DB. Contro: alcuni (piccoli) sovraccarichi DB aggiuntivi
• Salvalo nella sessione dell'utente. Contro: potenzialmente colpire ancora il database (se lo stato della sessione è memorizzato lì) o usare molta memoria (se lo stato della sessione è memorizzato lì) e potrebbe archiviare più copie se più utenti potrebbero accedere a questo oggetto e, peggio ancora, quella Sessione l'oggetto potrebbe sparire con l'utente hit submit se ASP.NET lo ha eliminato per qualsiasi motivo.
• Dalla cache. Contro: usa un po 'di memoria aggiuntiva e dovresti comunque andare al DB se la cache non esiste, ma metterei grandi soldi sul fatto che qualsiasi app ha molti colli di bottiglia più grandi su cui usare la cache.
• Viewstate. POTREBBE archiviare l'oggetto nel Viewstate (che lo invia al client, quindi il client lo registra nuovamente). Contro: la peggiore soluzione, secondo me. Aggiungendolo al Viewstate significa che sta andando oltre il filo a valle e a monte e fa sì che le dimensioni della pagina siano enormi. La sessione non è la migliore, ma Viewstate è il diavolo.

Answer 2

Hai molti utenti?

La memorizzazione degli oggetti business nella sessione potrebbe essere OK, se il tuo sito ha un volume basso.

Se si utilizza SQL Server per archiviare la sessione, si sta comunque caricando efficacemente l'oggetto business dal database per post.

Tuttavia, come regola generale, tendo a utilizzare Session per archiviare solo le informazioni applicabili alla durata della sessione degli utenti. Gli oggetti business specifici di un singolo modulo Web non rientrano realmente in questa categoria. Per i siti ad alto volume, questa strategia probabilmente ti aiuterà anche a ridimensionare meglio. Dipende solo da tutti i fattori in questione.

:)

Answer 3

Il ricaricamento di un oggetto dal database prima dell'aggiornamento è potenzialmente molto pericoloso. Puoi finire per perdere eventuali violazioni della concorrenza.

Ad esempio se si verifica questo flusso:

1. Visualizza la schermata di modifica per il cliente 1 sul computer 1
2. Visualizza la schermata di modifica per il Cliente 1 su Computer 2
3. Gestire l'aggiornamento al Cliente 1 dal Computer 1
4. Gestire l'aggiornamento al Cliente 1 dal Computer 2

È possibile che il (4) non riesca a causa di una violazione della concorrenza, ovvero l'aggiornamento sovrascrive le modifiche di cui Computer 2 non era a conoscenza. Ricaricando dal database, si ignorano questi problemi e si implementano le vittorie dell'ultimo aggiornamento.

Quindi, per questo tipo di situazione, sento che mettere l'entità originale nella sessione (o in un campo nascosto nel modulo) è assolutamente la cosa giusta da fare se ti interessa la concorrenza.

Per non parlare di molte persone che non amano colpire di nuovo il database per la lettura extra ...