¿Por qué alguna vez usaría el objeto de almacenamiento ViewState de asp.net sobre el objeto de almacenamiento de sesión?

Question

Aparte de porque el almacenamiento de la sesión es sesión-global para más de una página, ¿por qué alguna vez querría usar viewstate para mantener los valores?

Parece un poco ridículo enviar cualquier clase de información que no sea una pequeña cadena de consulta como valores, hacia adelante y hacia atrás desde el cliente al servidor. Me refiero a qué desperdicio de ancho de banda (!), Simplemente con fines de almacenamiento. La sesión, si bien es global en varias páginas, parece una alternativa completamente superior a viewstate.

Especialmente con los controles y las variantes de asp.net ajax, el viewstate podría hincharse rápidamente al rastrear los distintos estados y variables de todos esos controles y elementos html.

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

Tal vez me está faltando otro gran uso para el almacenamiento viewstate 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 elegí la tuya.

Answer 1

Sesiones se agotan, Viewstate no lo hace; puede volver una hora más tarde y su viewstate seguirá estando disponible. Viewstate también está disponible constantemente cuando retrocede/avanza en el sitio web. Cambios de sesión.

Answer 2

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 3

Está haciendo una aplicación donde viewstate bloat, en su mayor parte, no es un problema, entonces es mejor almacenar datos específicos de la página en el viewstate porque ayuda a su servidor a tener un mejor rendimiento. Si te vuelves loco con la sesión, o cualquier almacenamiento en caché, para el caso, puedes lastimarte más que a ti mismo.

Answer 4

ViewState es básicamente una entrada oculta que debe cargarse en el servidor y analizarse con cada solicitud. Este campo generalmente se rellena automáticamente, a menudo con el programador felizmente inconsciente, y puede crecer bastante grande. Para muchos sitios que presentan un problema, ya que incluso los usuarios de banda ancha tienen un ancho de banda muy ascendente.

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

Answer 5

No es una respuesta a su pregunta, pero una de sus suposiciones es incorrecta.

Los ID de sesión se pueden pasar en la URL. La sesión no requiere cookies.

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

<sessionState cookieless="true" /> 

Answer 6

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

Si no le gusta el comportamiento normal de ViewState, es bastante simple escribir su propia PageStatePersister y dejar que este objeto realice la persistencia, por ejemplo mediante sesión, o algo así como Memcached.A continuación, puede anular por completo el mecanismo de persistencia predeterminado.

Luego, lo bueno es que puede seguir utilizando controles web estándar en .NET Framework, que usará ViewState/ControlState para este tipo de datos, sin aumentar el tamaño de ViewState. Un mecanismo de persistencia de la memoria del servidor podría ser muy eficiente.

Answer 7

El motivo de Viewstate o Session es convertir la web de un sistema sin estado en una experiencia dinámica y personalizada. Cuando un usuario solicita una página, la única forma de reanudarla en su experiencia es recordar el estado en el servidor o en el cliente del usuario.

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

Viewstate es un mecanismo de almacenamiento transitorio. Los controles que usan viewstate tienen su estado procesado en la página html como una entrada oculta. Para evitar la manipulación, está firmado. Sin embargo, no está encriptado, por lo que probablemente quiera evitar poner ALGO sensible aquí. Viewstate es útil para situaciones en las que desea publicar en series de múltiples solicitudes (cargas de página). Un ejemplo de esto es cuando un formulario no valida porque tal vez el usuario ingresó una dirección de correo electrónico incorrecta o algo así, y desea restaurar el formulario tal como estaba antes de que el usuario lo enviara. La desventaja de esto es que viewstate es una bestia hambrienta y puede agregar fácilmente 30-50% al tamaño de la página.

La sesión, por otro lado, se almacena en el servidor. El cliente recibe un token que le dice al servidor qué bloque de memoria es suyo. Esto puede ser mucho más seguro que ViewState porque los datos no se vuelven a transmitir al usuario una y otra vez. Sin embargo, hay compensaciones. Su servidor puede quedarse sin memoria. O bien, el usuario podría perder los datos si se interrumpe su sesión.

Generalmente, no hay una respuesta "correcta" para usar. Se trata de lo que estás tratando de lograr.

La mayoría de las cosas que hacer con los controles debe usar Viewstate. Sin embargo, si está tratando con información confidencial, considere Sesión. Si tiene datos para un conjunto específico de páginas, use viewstate. Si se trata de datos que necesitará durante la visita de un usuario en su sitio, considier Session.

Answer 8

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

Puede almacenar el lado viewstate del servidor, eliminando la carga útil para el cliente.

Crea una clase hereda la página y anula la 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); 
      } 
     } 
    }