2009-01-08 20 views
7

Si tengo un simple dato para almacenar (un entero o una cadena, por ejemplo) podría elegir almacenar eso en ViewState, o usar un control de HiddenField.ViewState o HiddenField

¿Por qué elegiría una sobre la otra?

ViewState

  • duro para el usuario para decodificar (no creía imposible), lo que podría ser deseable

HiddenField

  • valor se puede utilizar en JavaScript

¿Hay otros pros y d contras?

+0

También puede almacenar datos en el objeto de sesión –

+0

Sí, podría almacenar en Session; sin embargo, en este escenario, los datos solo son relevantes para la página en cuestión, por lo que, por razones de encapsulación, preferiría almacenarlos en la página. –

+1

Almacenar los datos en la sesión esencialmente lo haría de alcance global. Almacenarlo en la página reduciría su alcance, que es la mejor práctica de diseño. –

Respuesta

6

No realmente, ViewState se almacena en realidad en un campo oculto, por lo que la única diferencia real es la codificación.

A menos que necesite manipular el valor con JavaScript o espere desactivar ViewState en esta página por completo, entonces usaría ViewState. Principalmente solo porque hay herramientas de terceros (like this one) que entienden ViewState y que no comprenderán su campo oculto personalizado.

+1

De manera predeterminada, está almacenado en un campo oculto; sin embargo, puede cambiar eso y [almacenar el ViewState en la sesión] (http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister%28v = vs.110% 29.aspx). –

0

El ViewState se almacena en la página, por lo que aumenta el tamaño de la página y puede causar performance issues.

También podemos configurar la aplicación a save the viewstate on server en lugar de en la página en sí que podría proteger de algunos problemas de seguridad.

Jomit

+0

No estoy seguro de que el argumento del tamaño de página sea válido aquí: el tamaño de la página aumentará independientemente de si almaceno mi valor en ViewState o agrego un control adicional a la página y almaceno el valor allí –

+0

Estoy de acuerdo con Richard E con respecto al tamaño de la página argumento; por otro lado, acuerde con Jomit sobre la posibilidad de almacenar viewstate en el servidor. –

3

Desde el punto de vista de mantenimiento, que haría uso de ViewState. Es menos código para que escriba, lo que se reduce a menos puntos de falla en su software. También significa que cualquier desarrollador que venga después le será más fácil mantener su solución.

Si no está del todo cómodo con eso, escriba un acceso directo a la propiedad en la página que actúa como fachada para recuperar el valor de ViewState. Más tarde, si se siente obligado a convertirlo en un campo oculto, el descriptor de acceso puede manejar ese conmutador sin problemas para el resto del código. Solo asegúrate de documentar tus razones para hacerlo.

0

Viewstate solo funciona en la página en la que se encuentra o en la que está registrando. Con un campo oculto se puede acceder a los datos de la página siguiente se desplaza a (así como otros datos) utilizando el método AnteriorPágina del objeto de página, así:

string term = ((TextBox)Page.PreviousPage.FindControl("txtSearchTerm")).Text; 
0

El campo oculto son invisibles en la página y su los valores se pueden ver en la fuente de la vista, pero el valor de view-state está codificado y no es legible.

El valor del campo oculto se publica en la página siguiente. (Nota: use server.transfer para obtener el valor de los campos ocultos).