2012-08-31 12 views
5

He estado escribiendo una serie de controles genéricos de ASP.NET, y una cosa que no logro entender es cuándo almacenar valores en viewstate, y cuándo asumir que está bien no hacerlo.¿Cómo decido qué almacenar en viewstate?

Por un lado, tiene sentido para almacenar todo el estado del control en el estado de vista, incluyendo propiedades como:

  • valores del cuadro de texto introducido por el usuario (o cualquier dato de forma)
  • opciones de configuración como la altura o el tamaño de página
  • Incluso cómo se ha compuesto el control, por ejemplo, almacenar todos los datos desde los que está construida una vista de cuadrícula, o la cuadrícula misma.

rendimiento Haciendo caso omiso, cuanto más se puede meter en el estado de vista el mejor, ya que los medios de control se comportará exactamente las mismas a través de las devoluciones de datos y nunca "accidentalmente" revertir un valor o "olvidar" que se ha desactivado. Pero viewstate no es gratis. Almacenar todo significa que el control ahora generará tanto el HTML como todas sus propiedades internas para crear ese HTML, que casi siempre duplicaría el resultado.

Mi pregunta no es sobre el rendimiento, sino sobre la estrategia. ¿En qué criterios decido poner una propiedad en viewstate? que estaba pensando algo como lo siguiente:

Si el usuario no puede cambiar una propiedad, entonces el servidor se ponga siempre de forma explícita, así que está bien para dejarlo fuera del estado de vista. Incluso para algo como color=red, el usuario no establece esta propiedad directamente; harán clic en un botón en otro lugar que establece indirectamente esta propiedad. Ese botón o su propietario debe mantener el estado, no el control que vuelve rojo el color.

Esta lógica implica que las únicas propiedades que debe entrar en estado de vista serían:

  1. Los elementos de formulario como <input> (y con Request.Form[c.UniqueID] esto se puede evitar todavía)
  2. propiedades que el usuario puede controlar interactivamente directamente en el control.

¿Tiene sentido esta lógica? Parece débil y me gustaría escuchar más de los expertos.

+1

También: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx es una lectura divertida – Patrick

Respuesta

4

Use ViewState para cosas que no son necesarias para que su control funcione.

Use ControlState para ver las cosas que son necesarias para que su control funcione incluso si ViewState está deshabilitado.

Los valores iniciales y la jerarquía de control (incluso los controles html) se compilan en archivos temporales ASP.NET cuando se solicita la página por primera vez. Por lo tanto, no necesitan almacenarse en ningún lugar cuando nunca se cambian (e incluso ViewState no los guardará).

Un control solo almacena propiedades en ViewState que han cambiado durante el ciclo de vida de la página (desde TrackViewState). Un control cuyo estado se modificó es "sucio". Por ejemplo, si cambia TextBox1.Text en page_load, ViewState.IsItemDirty("TextBox1.Text") devolvería true. Estos valores se almacenarán en ViewState.

Mire here y here. (Realmente recomiendo leer ambos artículos)

Control State vs. View State Example

0

Creo que tienes razón en preocuparte por la saturación de viewstate, pero ¿qué otras opciones tienes disponibles? Si no almacena sus datos variables allí, ¿dónde los colocará? (Es posible que desee considerar la eliminación de algunos elementos de configuración, tal vez no permita que el usuario cambie tantas propiedades).

3

Comprobar este artículo en MSDN que cubre cuándo, dónde y qué utilizar la gran cantidad de opciones de gestión del estado disponibles en ASP.NET la sección de estado de vista se publica a continuación para conveniencia - la comprobación de sus requisitos contra las ventajas y desventajas deben guiarle en el uso sobre una base de caso por caso:

Artículo completo aquí: http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx

Viewstate Extracto:

de estado de vista

páginas Web Forms proporcionan la propiedad ViewState como una estructura integrada para retener automáticamente los valores entre múltiples solicitudes de la misma página . El estado de vista se mantiene como un campo oculto en la página. Para obtener más información sobre , consulte Descripción general de la administración del estado de ASP.NET.

Puede usar el estado de visualización para almacenar sus propios valores específicos de página en viajes de ida y vuelta cuando la página se publique de nuevo. Por ejemplo, si su aplicación mantiene información específica del usuario, es decir, información que se utiliza en la página pero que no es necesariamente parte de ningún control, puede almacenarlo en estado de vista.

Las ventajas de utilizar el estado de vista son:

No se requieren recursos del servidor El estado de vista está contenido en una estructura dentro del código de la página.

Implementación simple El estado de visualización no requiere programación personalizada para usar. Está activado por defecto para mantener los datos de estado en los controles .

Características de seguridad mejoradas Los valores en estado de vista son hash, comprimidos y codificados para implementaciones Unicode, que proporciona más seguridad que el uso de campos ocultos.

Desventajas de utilizar el estado de vista son: Consideraciones sobre el rendimiento

Debido a que el estado de vista se almacena en la página sí, almacenar valores grandes pueden causar la página para reducir la velocidad cuando usuarios mostrarlo, y cuando consiguen eso. Esto es especialmente relevante para dispositivos móviles, donde el ancho de banda a menudo es una limitación.

Limitaciones del dispositivo Los dispositivos móviles pueden no tener la capacidad de memoria para almacenar una gran cantidad de datos de estado de visualización.

Posibles riesgos de seguridad El estado de la vista se almacena en uno o más campos ocultos en la página. Aunque el estado de vista almacena datos en un formato hash , aún puede manipularse. La información en el campo oculto se puede ver si la fuente de salida de la página se ve directamente, creando un posible problema de seguridad. Para obtener más información, consulte ASP.NET Seguridad de aplicaciones web y prácticas básicas de seguridad para aplicaciones Web .