Gestión del estado
Los distintos medios para mantener el estado
El protocolo HTTP, al ser un protocolo desconectado, hace que el servidor web y la aplicación no tengan ningún medio para "recordar" una consulta formulada por un agente. Los distintos procedimientos que sirven para superar esta dificultad se denominan técnicas de gestión del estado.
1. Campos ocultos
El lenguaje HTML dispone de campos ocultos. Estos campos se caracterizan por su nombre y su valor, de tipo texto. Esto se genera en tiempo de publicación de la página y se devuelve en el post del formulario.
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Prueba de campo oculto</title>
</head>
<body>
<script runat="server">
string valor;
</script>
<%
if (Request["campo_oculto"] != null && Request["campo_oculto"] != "")
valor = Request["campo_oculto"];
else
{
valor = DateTime.Now.ToShortTimeString();
Response.Write("Nuevo usuario conectado a las " + valor);
}
%>
<form id="form1" runat="server">
<input type="hidden" name="campo_oculto" value="<%= valor %>" />
<input type="submit" name="b" value="Recargar" />
</form>
</body>
</html>
Tras la primera ejecución de la página, el objeto Request no se alimenta con una entrada llamada campo_oculto. El valor se inicializa con la hora en curso, antes de publicarse mediante el atributo value del campo oculto del formulario. Cuando el usuario hace clic en el botón Recargar, se asigna valor al campo y desaparece el mensaje para el usuario.
2. El ViewState
El diseño anterior...
Las sesiones
Es muy frecuente conservar para cada usuario datos de todo tipo: preferencias de presentación, criterios de ordenación, selección de artículos... Los periodos de tiempo en los que se mantienen estos datos en la aplicación se denominan sesiones.
1. Uso del objeto Session
Respecto a las técnicas anteriores de mantenimiento de estado, las sesiones apenas consumen ancho de banda; solo se intercambia un testigo (formado por una cookie o una URI) que permite identificar al usuario. Los datos se conservan, de hecho, en el servidor de aplicaciones.
a. Memorización y búsqueda de un objeto
El objeto Session (propiedad de HttpContext.Current) se utiliza como una tabla hash: los objetos (o valores) memorizados están identificados mediante una clave que sirve de índice:
protected void cmd_redir_Click(object sender, EventArgs e)
{
Session["nombre"] = txt_nombre.Text;
Response.Redirect("session_page2.aspx");
}
Para encontrar un valor almacenado en la sesión desde otra página, conviene utilizar la misma clave y proceder a un tipado explícito:
protected void Page_Load(object sender, EventArgs e)
{
string nombre = Session["nombre"] as string;
Label1.Text = nombre;
}
Es, a su vez, necesario verificar que la entrada correspondiente a la clave existe, en caso contrario el indexador del objeto Session devuelve null y falla la conversión de tipo:
// la conversión de tipo peligra si no existe el dato idu de usuario
int id_user = (int)Session["idu"];
El siguiente código es, de este modo, más seguro:
// verificación
int id_user;
if(Session["idu"] != null)
id_user = (int)Session["idu"];
b. Inicialización...
Los objetos Application y Cache
1. El objeto Application
A diferencia del objeto Session, el objeto Application conserva los datos accesibles para todos los usuarios de un sitio web.
a. Uso
Como el objeto Session, Application se utiliza como un diccionario de términos identificados mediante claves.
protected void Page_Load(object sender, EventArgs e)
{
int c=0;
if (Application["contador"] != null)
c = (int)Application["contador"];
c++;
Application["contador"] = c;
Label1.Text = "Página visitada " + c + " veces";
}
Los datos se conservan tanto tiempo como permita el proceso de gestión del estado (aspnet_wp.exe, el servicio Windows de gestión del estado o SQL Server). No es necesaria ninguna cookie.
El objeto Application memoriza cualquier objeto que se le pase como referencia. El programador debe, no obstante, prestar atención para mantener los campos estáticos que, generalmente, no están serializados.
b. Bloqueo
Como varias páginas, solicitadas por distintos usuarios, pueden acceder simultáneamente al objeto Application, Microsoft proporciona un mecanismo de bloqueo.
Application.Lock();
Application["contador"] = c;
Application.UnLock();
Este mecanismo debe, por tanto, utilizarse con prudencia; el bloqueo afecta al conjunto de datos almacenados en el objeto Application. Como se trata de una sección crítica, el bloqueo creado bloquea los demás threads hasta que se libera. Esto entraña, a menudo, una degradación en el rendimiento. Es preciso, por tanto, asegurar el funcionamiento respecto al rendimiento general de la aplicación.
2. La caché de datos de aplicación Cache
Igual que hace el objeto Application, el objeto Cache conserva datos accesibles por todos los usuarios de un sitio web. No obstante, estos datos se pueden borrar cuando existen dependencias asociativas.
La sintaxis de inserción es, por tanto, un poco más compleja, puesto que hace falta precisar las dependencias.
a. Las dependencias temporales
El primer tipo de dependencia es el tiempo; el dato almacenado se conserva hasta una fecha (hora) absoluta.
protected void Page_Load(object sender, EventArgs e)
{ ...