domingo, 20 de julio de 2014

¿Cómo se administra el estado en ASP.NET?



Las aplicaciones/sitios web funcionan sobre el protocolo HTTP, el cual es un protocolo sin estado. ¿Qué queremos decir con esto? Cada solicitud que un usuario hace sobre una página web o aplicación web se atiende a medida que se recibe. Una vez procesada la solicitud se descartan sus datos. Una solicitud por ejemplo es cuando buscamos en Google. Si notan, lo que se digitó en la caja de búsqueda no se pierde, su estado se mantuvo. Debe existir un mecanismo que mantenga el valor que se ingresó y el protocolo HTTP no proporciona una solución.

Bueno, para entender mejor lo que deseamos explicar, tendremos que ver un poco las aplicaciones de escritorio. Estos programas de escritorio pueden manejar variables que preservan los valores que el usuario digita o cualquier otro valor, de tal manera que puedan ser accedidos o modificados fácilmente. A diferencia de las aplicaciones de escritorio, en un ambiente web HTTP no hay variables que se preserven. Al igual que ocurre en un entorno de escritorio, la web espera la interacción de un usuario, pero cada interacción actúa como un pedido nuevo al servidor.

El protocolo HTTP por defecto no admite estados (preservación de valores), lo que implica que el servidor web trata cada petición de un navegador como una petición independiente. Las aplicaciones/sitios web necesitan mantener los valores de los controles entre las peticiones que un mismo usuario realiza hacia el servidor, como por ejemplo, realizar una consulta con una palabra y que la palabra que el usuario digitó se siga observando en la caja de texto. Hay que aclarar que no solamente los valores de controles se deben de mantener, sino toda variable que sea usada del lado del servidor en nuestra programación.

Aquí una vez más entran en juego los frameworks, los cuales proporcionan mecanismos para mantener los estados de variables y controles, y quitan un peso de encima al programador. ASP.NET nos brinda varias maneras de hacer esto. 

ASP.NET puede manejar los estados de dos maneras: del lado del cliente o del lado del servidor. ¿Qué significa esto? Bien, veremos esto a continuación y en qué caso se deben de usar cada una de ellas.

Manejo de estado del lado del cliente

ViewState

La propiedad ViewState de una página proporciona un objeto para conservar valores entre las distintas solicitudes de una misma página. Este es el método predeterminado que la página utiliza para conservar los valores de las propiedades de la propia página y sus controles entre recorridos de ida y vuelta. 

ControlState

En ocasiones es necesario almacenar los datos del estado del control para que un control funcione correctamente. La propiedad ViewState se puede utilizar para este propósito, pero los desarrolladores pueden desactivar el ViewState en el nivel de página, interrumpiendo que el control trabaje eficazmente. La propiedad ControlState permite mantener la información de las propiedades que es específica de un control y que no se puede desactivar como ocurre con la propiedad ViewState.

Campos ocultos

ASP.NET permite almacenar información en un control HiddenField, que se representa como campo oculto estándar HTML (se acuerdan del input type hidden). Un campo oculto no se representa visiblemente en el explorador, pero se pueden configurar sus propiedades igual que las de un control estándar. Cuando se envía una página al servidor, el contenido del campo oculto se envía junto con los valores de otros controles. Un campo oculto actúa como repositorio de cualquier información específica de página que desee almacenar directamente en la página. 

Cookies

Una cookie es una cantidad pequeña de datos que se almacena en un archivo de texto en el sistema de archivos del cliente o que se mantiene en la memoria durante la sesión del explorador cliente. Contiene información específica del sitio que el servidor envía al cliente junto con el resultado de la página. Las cookies pueden ser temporales (con fechas y horas de expiración específicas) o permanentes. 

Las cookies se guardan en el dispositivo cliente y, cuando el explorador solicita una página, el cliente envía la información de la cookie junto con la información de la solicitud. El servidor puede leer la cookie y extraer su valor. Uno de los usos típicos es almacenar un símbolo (puede que cifrado) que indica que el usuario ya se ha autenticado en la aplicación.

QueryString

Un querystring es información que se anexa al final de la dirección URL de una página. Un ejemplo típico de cadena de consulta podría tener el siguiente aspecto:

http://www.contoso.com/lista_articulos.aspx?categoria=basica&precio=100

En la ruta de acceso de la dirección URL indicada anteriormente, el querystring empieza por un signo de interrogación (?) e incluye dos pares atributo-valor, uno de ellos se denomina "categoria" y el otro, "precio".

Los querystring proporcionan una manera sencilla pero limitada de mantener la información de estado. Por ejemplo, es una manera sencilla de pasar información de una página a otra. Sin embargo, en algunos exploradores y dispositivos de cliente la longitud de la dirección URL tiene una limitación de 2083 caracteres. 

Manejo de estado del lado del servidor

ApplicationState

ASP.NET permite guardar valores utilizando el ApplicationState, de cada aplicación web activa. El ApplicationState es un mecanismo de almacenamiento global al que se puede tener acceso desde todas las páginas de la aplicación web. Por tanto, el ApplicationState resulta útil para almacenar la información que se debe mantener en los recorridos de ida y vuelta al servidor y entre las solicitudes de las páginas.

SessionState

ASP.NET permite guardar valores utilizando el estado de sesión, de cada sesión de una aplicación web activa.

SessionState es similar a ApplicationState, con la diferencia de que el ámbito es la actual sesión del explorador. Si hay varios usuarios utilizando la aplicación, cada uno de ellos tendrá un estado de sesión distinto. Asimismo, si un usuario sale de la aplicación y vuelve más tarde, el segundo usuario tendrá un estado de sesión distinto al del primero.

No hay comentarios:

Publicar un comentario

Nota: solo los miembros de este blog pueden publicar comentarios.