Question

Supposons que vous ayez une page ASPX qui ne repose pas sur la session, mais sur l'état d'affichage pour la persistance entre les publications.

Si un utilisateur accède à cette page et part pour un long déjeuner, l'état d'affichage sera-t-il toujours valide à son retour ?

Était-ce utile?

La solution

Aucun ViewState n'est conservé dans le processus PostBack. Toutefois, vous pouvez remplacer les propriétés SavePageStateToPersistenceMedium () de la classe Page, et LoadPageStateFromPersistenceMedium (), pour implémenter ce comportement si vous le souhaitez. Pour plus d'informations, consultez Présentation de l'état de visualisation ASP.NET .

Notez que Page ViewState est stocké dans la session. Par conséquent, si votre session expire, le ViewState sera perdu. Je ne dirais pas que ViewState arrive à expiration, mais oui, il sera détruit après le délai d'attente de la session.

Autres conseils

Viewstate lui-même n'expire pas. Comme il est posté dans un formulaire, il peut être reconstitué à tout moment.

Selon MSDN : & "; .. il est possible que l'état d'affichage expire si une page n'est pas renvoyée dans le délai d'expiration de la session " ;. Ainsi, dans une certaine mesure, il peut expirer si votre session le fait, mais l'état d'affichage n'élimine pas directement. De toute façon, puisque vous n'utilisez pas l'état de session, vous n'avez pas à vous soucier de l'expiration implicite.

Notez que je n'aurais pas dit qu'il a expiré. C’était MS que j’avais cité dans leur propre article intitulé Contrôle de ViewState

Viewstate n'expire pas.

Toutes les données Viewstate sont stockées sur le client et sont renvoyées au serveur lorsque l'utilisateur exécute une publication.

Cela a des implications très intéressantes et est expliqué en détail ici .

En outre, par défaut, ASP.NET chiffre ViewState avec une clé générée automatiquement. Cela peut être remplacé par l'élément MachineKey dans le fichier web.congif. Même si ViewState n'expire pas, il peut devenir invalide si une autre clé générée automatiquement est utilisée pour déchiffrer ViewState, par exemple après une réinitialisation IIS, le redéploiement d'une application ou la frappe d'un serveur différent dans une batterie de serveurs Web. Si vous envisagez de stocker viewstate pendant de longues périodes, faites attention à la manière dont il est crypté / déchiffré.

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

Oui, ViewState expire dans certaines conditions. Par exemple, lorsque vous utilisez iframe: s ou lorsque vous gérez & "; live &"; connexion au serveur avec des publications régulières. Ensuite, vous voudrez peut-être examiner cette option: <sessionPageState historySize="9"/> qui code en réalité le nombre de & Quot; résultats de publication & "; sont stockés dans la session (si SessionPageStatePerster est utilisé). Chaque publication stocke son état ViewState jusqu'à la fin de la file d'attente de la session [& "; __ VIEWSTATEQUEUE &";] Et supprime les états ViewStates qui sont & "Trop anciens &". Et comment pensez-vous que SessionPageStatePerster décide quels ViewStates sont trop anciens? En configurant une taille_historique constante dans web.config .. Omg! C’est trop moi aussi pour toujours de trouver ce problème ... Ma haine pour la programmation asp.net est indescriptible maintenant .. grrr ...

Le Viewstate n'expire pas, tant qu'il reste sur la page, il sera toujours là et fonctionnel.

Le ViewState persistera de POST en POST.Il est en fait stocké dans un champ caché de votre formulaire afin qu'il soit renvoyé à tout moment sur votre serveur.

Tant que vous ne comptez pas sur la session, vous ne devriez avoir aucun problème à reconstruire l'état de la page.Il est cependant facile de tester le code d'état de votre page si vous le souhaitez :configurez simplement votre session pour qu'elle expire après 60 secondes dans votre web.config, puis chargez votre page, attendez un peu plus d'une minute (naviguez sur Stack Overflow et répondez à quelques questions), puis cliquez sur un bouton de votre page.

Désolé de revivre cet ancien fil de discussion, mais de nouvelles informations sont disponibles dès maintenant:

Oui, l'expiration de ViewStates . Je viens de 19 heures de recherche sur un problème de ViewStates perdre ses valeurs entre postbacks de long intervalle de temps. Il m'a fallu un certain temps pour lire les documents MSDN et les réponses de Stackoverflow affirmant qu'il était fondamentalement impossible de se produire si une implémentation de stockage ViewState personnalisée était utilisée, ce que je sais maintenant que ce n'est pas vrai.

Mon problème se déroulait dans un environnement SharePoint 2013. Le service appelé Cache distribué (a.k.a. AppFabric ) effectue la mise en cache du ViewState et est associé à un temps de vie . Vous pouvez trouver plus d'informations ici: http: // blogs .msdn.com / b / besidethepoint / archive / 2013/03/27 / appfabric-caching-and-sharepoint-1.aspx

L’information intéressante peut être trouvée dans cette phrase: " Pour améliorer les performances de la page, à partir de SharePoint 2013, le cache de données ViewState est mis en cache côté serveur, plutôt que d'être transféré aux clients. "

J'espère que cette information aidera quelqu'un d'aussi désespéré qu'il y a 19 heures.

ViewState est conservé dans un champ masqué sur la page elle-même. Donc, tant que l'utilisateur a la page, il aura le ViewState. Mais si votre application déconnecte automatiquement l'utilisateur au bout d'un certain temps, le fait de conserver ViewState risque de ne pas lui être bénéfique.

Par défaut, Viewstate est inclus avec le contenu HTML en tant qu'entrée masquée. Cela signifie qu'il n'expire pas, mais que tout dans viewstate doit être téléchargé à partir du navigateur de l'utilisateur. Étant donné qu’il s’agit généralement de la partie la plus lente de la connexion sur un site public, le fait de placer beaucoup de choses dans viewstate peut rapidement faire en sorte que votre site semble très lent.

La réponse courte est: non.

La réponse la plus longue est: cela dépend de la mise en œuvre du stockage ViewState. Vous pouvez fournir une implémentation personnalisée de ViewState qui peut expirer après un laps de temps donné. Par exemple, vous pouvez stocker ViewState dans une base de données ou sur un disque et n'envoyer qu'une référence à la valeur stockée dans un champ masqué. Vous pouvez ensuite utiliser le traitement par lots pour supprimer les données ViewState obsolètes ou effectuer une expiration sur demande.

Aucun Viewstate n'expire. Après avoir redirigé vers une autre page, la valeur de l'état d'affichage est perdue ou expire viewstate. pour plus de détails http: //www.c-sharpcorner .com / UploadFile / 78d182 / Techniques de gestion d’états Asp / Net /

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top