¿Por qué se ha consumido alguna vez objeto de almacenamiento ViewState de asp.net sobre el objeto de almacenamiento de sesión?

Question

Aparte de porque el almacenamiento de sesión es-sesión global a más de una página, ¿Por qué alguna vez que desee utilizar el estado de vista para contener valores?

Parece un poco ridículo para enviar cualquier tipo de información que no sea una cadena de consulta pocas pequeño, como los valores, de ida y vuelta desde el cliente al servidor. Me refiero a lo que es un desperdicio de ancho de banda (!), Simplemente con fines de almacenamiento. La sesión, mientras mundial a través de múltiples páginas, parece una alternativa completamente superior a la del estado de vista.

Especialmente con controles ASP.NET AJAX y variantes, el estado de vista podría convertirse rápidamente en hinchada seguimiento de los diversos estados y variables de todos los diferentes controles y elementos HTML.

Pero entonces ¿por qué hay almacenamiento de estado de vista para las variables de página y objetos en absoluto?

Tal vez me falta otro gran uso para el almacenamiento de estado de vista de la página, ¿alguien sabe algo por ahí?

Gracias por leer!

EDIT:. Todo el mundo tenía una gran respuesta, lo siento si no me tomo la suya

Answer 1

Las sesiones se agotan, Viewstate no - se puede volver una hora más tarde y su estado de vista seguirá estando disponible. Viewstate también es consistentemente disponibles cuando vas atrás / adelante en el sitio web, los cambios de sesión.

Answer 2

La razón para Viewstate o sesión es para convertir la banda de un sistema sin estado en una experiencia dinámica y personalizada. Cuando un usuario solicita una página, la única manera de que pueda reanudar donde el usuario lo dejó en su experiencia es recordar el estado ya sea en el servidor o en el cliente del usuario.

Viewstate es un mecanismo para recordar el estado del usuario en el cliente. Sesión es un mecanismo para recordar el estado del usuario en el servidor.

Viewstate es un mecanismo de almacenamiento transitorio. Los controles que utilizan estado de vista tienen su estado prestados en la página HTML como un campo oculto. Para evitar la manipulación indebida, se firmó. No está encriptada, sin embargo, por lo que probablemente quiere evitar poner nada sensibles en allí. Estado de vista es útil para situaciones en las que desee publicar en toda serie de múltiples peticiones (cargas de página). Un ejemplo de esto es cuando una forma no valida porque tal vez el usuario introduce una dirección de correo electrónico mal o algo, y si desea restaurar la forma como lo era antes de que el usuario envió. Las desventajas de este estado de vista es que es una bestia hambrienta y puede agregar fácilmente un 30-50% al tamaño de la página.

Sesión, por el contrario, se almacena en el servidor. El cliente obtiene un símbolo que indica al servidor qué bloque de la memoria es de ellos. Esto puede ser mucho más seguro que el estado de vista porque los datos no está siendo retransmitida al usuario una y otra vez. Hay ventajas y desventajas, aunque. Su servidor puede quedarse sin memoria. O bien, el usuario podría perder los datos si se interrumpe la sesión.

En general, no hay una respuesta "correcta" en el que se utilice. Es todo acerca de lo que está tratando de lograr.

La mayoría de cosas que hacer con los controles deben utilizar Viewstate. Si estás tratando con información sensible sin embargo, considerar la sesión. Si tiene datos que es para un conjunto específico de páginas, utilice estado de vista. Si se trata de datos que necesitará a lo largo de la visita de un usuario en su sitio, considier sesión.

Answer 3

Por ejemplo, cuando su aplicación se esté ejecutando en una granja de la computadora y no se puede configurar la sesión para usar el servidor SQL. (O usando el servidor SQL es demasiado de un impacto en el rendimiento)

Answer 4

ViewState y Sesión tienen diferentes alcances. ViewState está diseñado para almacenar datos más o menos transitorios, durante las "devoluciones", mientras que la sesión se utiliza para guardar los datos críticos de estado de sesión. Recomiendo el uso de ViewState de estado relacionada con una "sesión de página" específica.

Si no te gusta el comportamiento normal de ViewState, es bastante fácil de escribir su propio PageStatePersister y dejar que este objeto realizar la persistencia, por ejemplo usando sesión, o algo así como Memcached. A continuación, puede anular por completo el mecanismo de persistencia predeterminado.

A continuación, lo bueno es que se puede perfectamente seguir utilizando controles web estándar en el .NET Framework, lo que todo el uso ViewState / ControlState para este tipo de datos, sin inflar el ViewState. Un mecanismo de persistencia memoria del servidor podría ser muy eficiente.

Answer 5

No es realmente una respuesta directa a su pregunta, pero puede resolver su problema.

Puede almacenar estado de vista del lado del servidor, eliminando la carga útil para el cliente.

Crea una clase hereda la página, y anular el PageStatePersister. http://msdn.microsoft.com/en- es / library / system.web.ui.sessionpagestatepersister.aspx

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

Answer 6

ViewState es esencialmente sólo un campo oculto que debe ser cargado en el servidor y analiza con cada solicitud. Este campo se rellena automáticamente normalmente, a menudo con el programador felizmente inconsciente, y puede llegar a ser muy grande. Para muchos sitios que se presenta un problema, porque incluso los usuarios de banda ancha tienen ancho de banda ascendente muy limitado.

En los sitios de intranet donde todos los usuarios tienen acceso a internet de alta velocidad para el servidor, pero la RAM disponible para el almacenamiento de datos de sesión es limitado, puede tener más sentido.

Answer 7

No es una respuesta a su pregunta, pero uno de sus supuestos no es correcta.

identificadores de sesión se puede pasar en la URL. Sesión no requiere cookies.

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

<sessionState cookieless="true" />

Answer 8

Usted está haciendo una aplicación donde la hinchazón estado de vista, en su mayor parte, no es un problema, entonces es mejor a la página del almacén de datos específicos en el estado de vista, ya que ayuda a su servidor funcione mejor. Si se vuelve loco con la sesión, o cualquier almacenamiento en caché, por lo demás, puede lastimarse a sí mismo más de lo que ayudarse a sí mismo.