Perché dovresti utilizzare l'oggetto di archiviazione ViewState di asp.net sull'oggetto di archiviazione Session?

Question

A parte il fatto che la memoria di sessione è globale di sessione a più di una pagina, perché dovresti voler utilizzare il viewstate per contenere i valori?

Sembra quasi ridicolo inviare qualsiasi tipo di informazione diversa da una piccola stringa di query come valori, avanti e indietro dal client al server. Intendo che spreco di larghezza di banda (!), Semplicemente per scopi di archiviazione. La sessione, sebbene globale su più pagine, sembra un'alternativa completamente superiore allo stato di visualizzazione.

Soprattutto con i controlli e le varianti di asp.net ajax, il viewstate potrebbe diventare rapidamente gonfio tenendo traccia dei vari stati e variabili di tutti i diversi controlli e elementi HTML.

Ma allora perché c'è lo storage viewstate per le variabili di pagina e gli oggetti?

Forse mi manca un altro grande utilizzo per lo spazio di visualizzazione della pagina, qualcuno sa qualcosa?

Grazie per la lettura!

EDIT: Ognuno ha avuto un'ottima risposta, mi dispiace se non ho scelto il tuo.

Answer 1

Sessions esaurito, Viewstate no - puoi tornare un'ora più tardi e il tuo stato di visualizzazione sarà ancora disponibile. Viewstate è anche costantemente disponibile quando si torna indietro/avanti sul sito Web, le modifiche della sessione.

Answer 2

Per esempio, quando la vostra applicazione potrebbe essere in esecuzione in una fattoria del computer e non è possibile configurare la sessione per utilizzare il server SQL. (O l'utilizzo del server SQL è troppo di un calo di prestazioni)

Answer 3

Stai facendo un'app in cui viewstate bloat, per la maggior parte, non è un problema, quindi è meglio memorizzare dati specifici della pagina nel viewstate perché aiuta il tuo server a funzionare meglio. Se impazzisci con la sessione o con la memorizzazione nella cache, del resto, puoi farti del male più di te stesso.

Answer 4

ViewState è essenzialmente solo un input nascosto che deve essere caricato sul server e analizzato ad ogni richiesta. Questo campo viene in genere popolato automaticamente, spesso con il programmatore beatamente inconsapevole e può crescere abbastanza grande. Per molti siti che presenta un problema, perché anche gli utenti a banda larga hanno una larghezza di banda upstream molto limitata.

Su siti intranet in cui tutti gli utenti hanno accesso LAN ad alta velocità al server ma la ram disponibile per contenere i dati di sessione è limitata, potrebbe avere più senso.

Answer 5

Non è una risposta alla tua domanda ma una delle tue ipotesi è errata.

Gli ID di sessione possono essere passati nell'URL. La sessione non richiede i cookie.

http://msdn.microsoft.com/en-us/library/aa479314.aspx

<sessionState cookieless="true" /> 

Answer 6

ViewState e Session hanno diversi ambiti. ViewState è progettato per memorizzare più o meno dati transitori, durante i "postback", mentre la sessione viene utilizzata per salvare i dati di stato della sessione critici. Consiglio di utilizzare ViewState per lo stato correlato a una specifica "sessione di pagina".

Se non ti piace il normale comportamento di ViewState, è piuttosto semplice scrivere il tuo PageStatePersister e lasciare che questo oggetto esegua la persistenza, ad esempio usando la sessione, o qualcosa come Memcached.È quindi possibile ignorare completamente il meccanismo di persistenza predefinito.

Quindi, la cosa buona è che puoi continuare a utilizzare i controlli web standard in .NET Framework, che utilizzeranno ViewState/ControlState per questo tipo di dati, senza sovraccaricare ViewState. Un meccanismo di persistenza della memoria del server potrebbe essere molto efficiente.

Answer 7

La ragione per Viewstate o sessione è di trasformare il web da un sistema stateless in una dinamica esperienza, personalizzata. Quando un utente richiede una pagina, l'unico modo per riprendere da dove l'utente ha interrotto la propria esperienza è ricordare lo stato sul server o sul client dell'utente.

ViewState è un meccanismo per ricordare lo stato dell'utente sul client. Sessione è un meccanismo per ricordare lo stato dell'utente sul server.

Viewstate è un meccanismo di memorizzazione temporaneo. I controlli che utilizzano viewstate hanno il loro stato reso nella pagina html come input nascosto. Per evitare manomissioni, è firmato. Tuttavia, non è crittografato, quindi probabilmente vorrai evitare di mettere TUTTO ciò che è sensibile. Viewstate è utile per le situazioni in cui si desidera pubblicare una serie di richieste multiple (caricamento della pagina). Un esempio di ciò è quando un modulo non viene convalidato perché forse l'utente ha inserito un indirizzo email errato o qualcosa del genere e si desidera ripristinare il modulo come era prima che l'utente lo sottoponesse. Il lato negativo di questo è che viewstate è una bestia affamata e può facilmente aggiungere il 30-50% alle dimensioni della pagina.

Sessione, d'altra parte, è memorizzata sul server. Il client riceve un token che comunica al server quale blocco di memoria è loro. Questo può essere molto più sicuro di viewstate perché i dati non vengono ritrasmessi all'utente ripetutamente. Ci sono comunque dei compromessi. Il tuo server può esaurire la memoria. Oppure, l'utente potrebbe perdere i dati se la loro sessione è interrotta.

In generale, non c'è una risposta "giusta" sulla quale utilizzare. È tutto su ciò che stai cercando di realizzare.

La maggior parte delle operazioni con i controlli deve utilizzare Viewstate. Se hai a che fare con informazioni sensibili, considera Sessione. Se si dispone di dati relativi a un set specifico di pagine, utilizzare viewstate. Se si tratta di dati di cui avrete bisogno durante la visita di un utente sul vostro sito, prendete in considerazione Session.

Answer 8

Non proprio una risposta diretta alla tua domanda, ma può risolvere il problema.

È possibile memorizzare lato server ViewState, eliminando il carico utile per il cliente.

creare una classe pagina eredita, e sovrascrivere il PageStatePersister. http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

public class RussPage : Page 
    { 
     protected override PageStatePersister PageStatePersister 
     { 
      get 
      { 
       return new SessionPageStatePersister(Page); 
      } 
     } 
    }