Non viewstate scadenza?

Supponiamo di avere una pagina aspx che non si basa su di sessione, ma non contare su di viewstate per la persistenza tra i vari postback.

Se un utente accede a questa pagina, e parte per un lungo pranzo, sarà viewstate ancora essere valido quando torna?

InformationsquelleAutor Aheho | 2008-10-24

 

12 Replies
  1. 9

    Non ViewState viene mantenuta come parte del PostBack processo. Si può, comunque, ignorare la Pagina della classe SavePageStateToPersistenceMedium() e LoadPageStateFromPersistenceMedium(), per implementare tale comportamento, se desiderato. Per ulteriori informazioni, leggere La comprensione del ASP.NET ViewState.

    Nota che Pagina ViewState è memorizzato in Sessione quindi, se la Sessione scade, il ViewState sarà perso. Non direi che questa è ViewState in scadenza, ma sì, sarà distrutto dopo il timeout di Sessione.

    • Come è “No” contrassegnato come risposta? Viewstate non scade, è forma variabili. Registrato nel credenziali utente può scadere in questo scenario, ma questo è tutto.
    • Io non sono nemmeno sicuro se wprl la risposta è “No”. dipende se c’è una virgola mancante, dopo la parola: “No”. In ogni modo sto cercando di capire che cosa questa risposta sta cercando di dire
  2. 14

    Viewstate di per sé non ha scadenza. Dal momento che è scritto in una forma, può essere ricostituito in qualsiasi momento.

    Secondo MSDN: “...è possibile che lo stato di visualizzazione per scadere se una pagina non viene inviato entro la scadenza della sessione tempo“. Così, in un giro in un certo modo, può scadere se la sessione, ma viewstate non direttamente scadenza. Visto che non stai usando lo stato della sessione, comunque, non è necessario preoccuparsi di implicita di scadenza.

    Nota che non mi hanno detto è scaduto. Che era MS che ho citato nel loro articolo intitolato Controllo ViewState

    • Che “il controllo di viewstate’ è un articolo sul movimento viewstate in sessioni di svolgere al meglio sulla base di clienti come i telefoni. Se si fa questo e utilizzare l’impostazione predefinita salva-viewstate in sessione, mantiene il viewstate in sessione, e mantiene solo l’ultimo X viewstates nella sessione. Ma questo non significa che non viewstate scade – il che significa che la sessione scade, e si sono spostati viewstate in sessione invece di utilizzare il modulo di variabili. Penso che stai mescolando due cose diverse qui.
  3. 5

    Viewstate non ha scadenza.

    Tutti viewstate i dati vengono memorizzati sul client e viene inviato al server quando l’utente esegue il postback.

    Questo è molto interessante per le implicazioni, ed è spiegato molto bene qui.

  4. 5

    Inoltre, come ti ho beccato, per impostazione predefinita ASP.NET crittografa ViewState con un generata automaticamente chiave. Questo può essere sostituito con il MachineKey elemento nel web.congif file. Anche se ViewState non ha scadenza, può diventare non validi se un diverso generata automaticamente chiave viene utilizzata per decrittografare ViewState, come dopo una Reimpostazione di IIS, ridistribuire l’applicazione, o colpire un altro server in una web farm. Se si sta pianificando la memorizzazione di viewstate per lunghi periodi di tempo, guardare fuori per come è crittografato/decifrati.

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

  5. 5

    Sì, ViewState scade in determinate condizioni. Per esempio quando si utilizza un iframe:s, o quando la manutenzione di “vivere” la connessione al server con regolare postback. Allora si potrebbe desiderare di indagare su questa opzione: <sessionPageState historySize="9"/>, che in realtà rigido codici di quante “postback risultati” sono memorizzati nella Sessione (se SessionPageStatePerster è utilizzato). Ogni postback memorizza ViewState alla fine della Coda in Session[“__VIEWSTATEQUEUE”], ed elimina ViewStates che sono “troppo vecchio”. E come pensi che SessionPageStatePerster decide che ViewStates sono troppo vecchio.. configurando arbitrario historySize-costante nel web.config.. Omg! Si anche a me sempre a trovare il problema… il Mio odio verso asp.net la programmazione è indescrivibile ora.. grrr…

  6. 2

    Il ViewState persistono da POST a POST. In realtà è memorizzato all’interno di un campo hidden nel form in modo che esso viene Inviato al server per tutto il tempo.

    Finchè non fare affidamento sulla Sessione non dovrebbe avere problemi di ricostruzione dello stato della pagina. È facile di testare la vostra Pagina di stato del codice, se si desidera, anche se: basta impostare la sessione scade dopo 60 secondi del web.config e poi caricare la tua pagina, attendere poco più di un minuto (surf su Stack Overflow e rispondere ad alcune domande) e quindi fare clic su un pulsante sulla tua pagina.

  7. 2

    Mi dispiace per rivivere questo vecchio thread, ma le nuove informazioni è disponibile ora:

    Sì, ViewStates scadenza. Io vengo da 19 ore di ricerca su un problema di ViewStates perdere i suoi valori tra intervallo di tempo di postback. Mi ci è voluto un po ‘ la lettura di documenti di MSDN e Stackoverflow risposte dicendo che era praticamente impossibile che accada, a meno che un custom ViewState di archiviazione di attuazione è stato impiegato, che, ora so, che non è vero.

    Il mio problema era che si svolgono in un ambiente SharePoint 2013. Il servizio noto come Cache Distribuita (un.k.un. AppFabric) la memorizzazione nella cache del ViewState e ha un Tempo per Vivere ad esso associati. Potete trovare ulteriori informazioni qui:
    http://blogs.msdn.com/b/besidethepoint/archive/2013/03/27/appfabric-caching-and-sharepoint-1.aspx

    Interessante bit di informazioni possono essere trovate in questa frase:
    “Per migliorare le prestazioni di una pagina, a partire da SharePoint SharePoint 2013 cache ViewState dati lato server piuttosto che il trasferimento di avanti e indietro per i clienti.”

    Spero che queste informazioni aiuta qualcuno così disperato come avevo 19 ore fa.

  8. 1

    ViewState è tenuto in un campo nascosto nella pagina stessa. Quindi, fintanto che l’utente ha la pagina, avrà il ViewState. Ma se la tua app registra automaticamente l’utente, dopo un certo periodo di tempo, pur avendo il ViewState non possono fargli nulla di buono.

  9. 1

    Per impostazione predefinita, il Viewstate è incluso con il contenuto html come un input nascosto. Il che significa che non scadono, ma tutto ciò che nel viewstate deve essere caricato dal browser dell’utente. Dal momento che in genere la parte più lenta di connessione in un sito pubblico, mettendo un sacco di roba in viewstate può rapidamente rendere il vostro sito sembra molto lento.

  10. 1

    La risposta breve è: no.

    La risposta è più: dipende dall’implementazione del ViewState di archiviazione. È in grado di fornire personalizzati attuazione del ViewState che potrebbe scadono dopo un determinato periodo di tempo. Per esempio, si potrebbe salvare il ViewState in database o su disco e di inviare solo qualche riferimento al valore memorizzato in un campo nascosto. Quindi è possibile utilizzare l’elaborazione in batch per rimuovere obsoleto ViewState dati o eseguire scadenza su richiesta.

Lascia un commento