Mantenere i dati in sessione vs. popolare in postback

Question

Cosa è preferibile, mantenere un set di dati in sessione o riempire il set di dati su ciascun postback?

Answer 1

Ciò dipenderebbe da molti fattori. Di solito è meglio non conservare troppi elementi nella memoria della sessione se la sessione è inproc o su un server di stato perché è meno scalabile.

Se la sessione risiede nel database, potrebbe essere meglio richiedere e ripopolare il set di dati a meno che la query non sia costosa da eseguire.

Answer 2

Non usare la sessione !!! Se l'utente apre una seconda scheda con una richiesta diversa, la sessione verrà riutilizzata e i risultati non saranno quelli che si aspetta. È possibile utilizzare una combinazione di ViewState e Session ma misurare comunque quanto è possibile gestire senza alcun tipo di memorizzazione nella cache prima di ricorrere alla memorizzazione nella cache.

Answer 3

Dipende da quanto pesantemente lo farai e da dove sono archiviati i dati della sessione sul server.

Mantenere i set di dati in sessione influisce sicuramente sul utilizzo della memoria . Tutte le variabili di sessione sono archiviate in memoria o nel server SQL se si utilizza lo stato di SQL Server. Puoi anche scaricare il carico su un altro computer usando la modalità State Server.

L'aspetto serializzazione / deserializzazione. Se si utilizzano insiemi di dati follemente grandi, ciò potrebbe influire negativamente sulle prestazioni del server.

D'altra parte, avere viewstate molto grandi sulle pagine può essere un vero killer delle prestazioni . Quindi terrei i set di dati in sessione o nella cache e cerco un "outproc" modo per memorizzare i dati di quella sessione.

Answer 4

Dato che voglio il minor numero possibile di operazioni sul database, manterrò i dati in sessione, ma non sono sicuro di quale sarebbe il modo migliore per farlo. Come posso gestire la concorrenza e anche dal momento che i dati sono condivisi quando due utenti utilizzano contemporaneamente la pagina come posso assicurarmi che ognuno di loro abbia il proprio set di dati nella sessione?

Answer 5

Di solito lo tengo in sessione se non è troppo grande e / o il db è lungo e lento. Se i dati sono grandi, in generale, è meglio ricaricare.

A volte uso la cache, la prima volta che carico da Db e la metto nella cache. Durante il postback controllo la chache e se è vuota ricarica. Quindi il server gestisce la cache da solo.

Answer 6

il problema con la sessione è che se è in proc potrebbe scomparire, il che non è eccezionale, se si tratta di un server di stato, allora devi serializzare e se è sql stai facendo comunque un viaggio di andata e ritorno!

se il set di risultati è grande, esegui il paging personalizzato in modo da restituire solo un piccolo sottoinsieme dei risultati totali.

quindi se ritieni che più di un utente vedrà questo set di risultati inserisci ogni pagina nella cache come le pagine dell'utente assicurandoti che la cache venga rinnovata quando i dati cambiano o dopo un po 'di tempo non sono accessibili.

se non vuoi fare molti round trip e pensi di avere la memoria, metti tutto il set di dati nella cache ma fai attenzione a non fondere il web server.

l'uso della cache significa che gli utenti non hanno bisogno del proprio set di dati piuttosto che usano il set globale.

per quanto riguarda la concorrenza quando si carica la pagina di inserimento / modifica, è necessario popolarla con nuovi dati e rinnovare la cache dopo l'aggiunta / aggiornamento.

Answer 7

Sono un grande sostenitore del disaccoppiamento e raramente, se mai, vedo la necessità di inviare un set di dati completo all'interfaccia utente.

Dovresti davvero solo passare oggetti all'interfaccia utente che deve essere utilizzata, quindi a meno che tu non mostri un diagramma grande o una sorta di struttura di dati che deve mostrare relazioni tra i dati non vale il costo.

Sottoinsiemi di dati più piccoli, quando applicabile, sono molto più efficienti. L'applicazione sta effettivamente utilizzando tutte le funzionalità all'interno di un set di dati sull'interfaccia utente? in caso contrario, il modo migliore per procedere sarebbe quello di trasmettere solo i dati che stai visualizzando.

Se stai vincolando i dati a un controllo e ordinando / paging ecc. tramite esso, puoi implementare molte interfacce che consentono al set di dati di supportarlo, in un pezzo di codice molto più piccolo.

In quella nota, terrei i dati, che sono in gran parte statici (ad es. non si aggiornano così spesso) nella cache. Quindi è necessario esaminare la frequenza con cui i dati vengono aggiornati prima di poter davvero prendere una decisione in tal senso.

Infine, lo dirò di nuovo, vedo la necessità di utilizzare un set di dati nell'interfaccia utente molto, molto raramente ... è un oggetto dati molto pesante e i vantaggi in termini di costi derivanti dall'esame dei requisiti dei dati, rispetto alla facilità di implementazione , potrebbe superare di gran lunga la necessità di memorizzare nella cache un set di dati.

IMHO, i set di dati sono piuttosto male da usare se sei preoccupato per le prestazioni o l'utilizzo della memoria.

Answer 8

La tua risposta non allude all'utilizzo dei dati. Sono dati di riferimento? L'utente lo sta aggiornando attivamente? È più di un utente destinato ad avere accesso agli aggiornamenti contemporaneamente?

Senza alcuna informazione migliore di quella fornita, vai con la saggezza accettata secondo cui mantenere grandi quantità di dati in sessione è un modo per garantire che la tua applicazione non riduca e richieda risorse pesanti per servire una manciata di persone.

Di solito ci sono modi migliori per gestire set di dati di grandi dimensioni senza ricorrere al caricamento di tutti i dati in memoria.

In caso contrario, se i dati delle tue applicazioni sono veramente mostruosi, considera un client pesante con un back-end del servizio web. Potrebbe essere più adatto che creare una pagina Web.

Answer 9

Come hanno notato altre risposte, la risposta "dipende". Tuttavia supporrò che stai parlando di dati condivisi tra utenti. In tal caso dovresti non archiviare il set di dati nella sessione dell'utente, ma ripopolarlo al postback.

Inoltre, è necessario popolare una cache vicino al livello di accesso ai dati dell'applicazione per aumentare le prestazioni interattive e ridurre il carico sul database. Il design della cache dipenderà nuovamente dal tipo di dati (sola lettura vs. lettura / scrittura e lettura-per lo più).

Questo approccio separa la sessione dell'utente (un concetto a livello di interfaccia utente) dalla gestione dei dati e offre il vantaggio aggiuntivo di supportare l'uso condiviso dei dati memorizzati nella cache (nei casi in cui i dati sono comuni tra gli utenti).

Answer 10

Né - non " mantenere " nulla! Mostra solo ciò che un utente deve vedere e crea uno schema di paging efficiente per vedere le file all'indietro o in avanti.

rp

Answer 11

Mantieni in sessione. Se necessario, puoi ripopolarlo, ad esempio se si cancella la memoria della sessione.