Programación II

Programación II
Clase Teórica Nº 3
Proyectos Web Forms con ASP.NET.
Uso de sesiones y cookies.

Objetivos

Al final de la clase los estudiantes serán capaces de:

▪ Comprender el funcionamiento de los proyectos Web Forms en ASP.NET.
▪ Comprender en qué consisten las cookies y sesiones.
▪ Implementar el uso de cookies y sesiones en una aplicación en ASP.NET.

Introducción

Como su nombre lo indica, el procesamiento del lado del servidor es aquel que se ejecuta en el servidor Web,
justo antes de que se envíe la página a través de Internet al cliente, las páginas que se ejecutan en el servidor
pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el
cliente, el cliente solamente recibe una página con el código HTML resultante de la ejecución en el servidor,
como la página resultante contiene únicamente código HTML, es compatible con casi todos los navegadores.
Existen diferentes tecnologías que se utilizan para llevarlo a cabo, entre las que mencionaremos los CGI’s,
ASP.NET, PHP.

Desarrollo

Funcionamiento de una aplicación Web en ASP.NET.

• Al hacer la petición, el servidor se percata que la página requerida es ASP.NET (archivo aspx).
• La página, que es tratada como un programa, primeramente es procesada por un analizador de código
(Parser), que verifica que el programa está bien escrito y que no tiene errores de sintaxis o de
referencias perdidas (uso de variables, procedimientos, o miembros inexistentes).
• Si el programa no tiene errores de sintaxis o de referencias perdidas, el programa es puesto a disposición
del compilador de páginas de .NET Framework.
• El compilador se encargará de generar un ensamblado de extensión DLL, de nombre único, que define
una clase capaz de generar el código HTML que ha de ser retornado al navegador del cliente.
• Este ensamblado es almacenado en un área denominada caché de ensamblados (Assembly Caché), en
donde se almacenan todos los ensamblados generados por el compilador de páginas.
• Luego que está generado el ensamblado capaz de producir el contenido web que ha de ser retornado al
cliente, un elemento denominado HTTP Runtime se encarga de solicitar la ejecución de la clase
generada, creando la instancia del objeto generador, produciendo entonces el contenido web.
• El contenido web generado por la clase es almacenado en un área denominada caché de salida (Output
Caché). En ese espacio se almacenan los contenidos HTML, los scripts de ejecución del lado del cliente,
e incluso los datos generados como parte de la salida, de ahí el contenido es enviado al cliente
solicitante.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 47
Programación II

• Si posteriormente se solicita la misma página, se buscará primeramente en Output Caché; si el contenido

web se encuentra todavía ahí, no se realizará procesamiento alguno, por lo cual la respuesta es
extremadamente rápida.

Formularios Web Forms.

Los formularios web (Web Forms) representan la parte más visible de los sitios web ASP.NET y, en
consecuencia, la más popular.
Se basan en un reparto de responsabilidades de tipo MVC: modelo, vista, controlador. Cuando se escribe un
formulario utilizando el estilo código independiente, la página HTML aspx se encarga de la representación
(vista), la clase C# gestiona los datos y los cálculos realizados con ellos (modelo), mientras que el servidor de
aplicaciones ASP.NET coordina el conjunto (controlador).

Procesado de Formularios.
Los formularios Web Forms están formados por una combinación de HTML, código y controles que se ejecutan
en un servidor Web ejecutando Microsoft Internet Information Services (IIS).
Los formularios Web Forms muestran una interfaz de usuario que genera HTML y que se envía al navegador,
mientras que el código de soporte y los controles que la componen permanecen en el servidor Web. Esta división
entre la interfaz en el cliente y el código en el servidor es una importante diferencia entre los formularios Web
Forms y las páginas Web tradicionales.
Mientras una página Web tradicional requiere que todo el código se envíe y se procese en el navegador, los
formularios Web Forms únicamente necesitan enviar al navegador los controles de la interfaz, y el proceso de las
páginas se mantiene en el servidor.
Esta división entre UI y código aumenta el número de navegadores soportados e incrementa la seguridad y
funcionalidad de la página Web, los formularios Web Forms se denominan habitualmente páginas ASP.NET o
páginas ASPX, los formularios Web Forms tienen una extensión aspx y funcionan como contenedores para el
texto y los controles que deseamos mostrar en el navegador.
Las páginas ASP.NET (aspx) y Active Server Pages (ASP) (archivos asp) pueden coexistir en el mismo
servidor. La extensión del archivo determina si la página la procesa ASP o ASP.NET.

Los formularios Web Forms están frecuentemente formados por dos archivos distintos: el archivo aspx contiene
la UI para el formulario Web Forms, mientras que el archivo aspx.cs denominado página de código subyacente,
contiene el código de soporte.
Las funciones de un formulario Web Forms están definidas por tres niveles de atributos:
▪ Los atributos de página definen las funciones globales.
▪ Los atributos de cuerpo definen cómo se mostrará una página.
▪ Los atributos de formulario definen cómo se procesarán los grupos de controles.

La etiqueta (directiva) <@ Page> define atributos específicos de la página que utiliza el parser de páginas
ASP.NET y el compilador.
Únicamente podemos incluir una etiqueta <@ Page> por archivo aspx.

Los siguientes ejemplos son etiquetas <@ Page>:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="WebForm1.aspx.cs" Inherits="WebForm1" %>

______________________________________________________________________________________________________________
Ciclo 01 – 2024 48
Programación II

Los atributos de una etiqueta <@ Page> incluyen:

Language: este atributo define el lenguaje en el que está escrito el script de la página Web. Algunos de
los valores de este atributo son: VB, C# y JScript.

CodeFile: este atributo de página identifica la página de código subyacente que tiene la lógica que
soporta el formulario Web Form. Cuando se crea un formulario Web Form, como WebForm1.aspx,
también se crea una página de código subyacente, WebForm1.aspx.cs.

Las directivas organizan la lectura de una página aspx en el servidor de aplicaciones.

Hay otros atributos presentes, que sirven para la comunicación con la página de codebehind (AutoEventWireup,
CodeFile, Inherits), para aplicar temas, para la gestión de trazas.
Visual Studio proporciona distintos atributos aplicables utilizando la combinación de teclas Ctrl+Espacio.

Existen otras directivas disponibles para incluir recursos en el entorno de la página: estrategia de caché,
componentes, ensamblados, tipos de página maestra.

Los atributos de la etiqueta <body> definen el aspecto de los objetos que se muestran en el navegador del cliente.

La etiqueta <form> define cómo se procesarán los grupos de controles. La etiqueta <form> es diferente del
término Web Forms utilizado para definir la página Web completa.
Los atributos de la etiqueta <form> definen cómo se procesarán los controles. Aunque podemos tener muchos
formularios HTML en una página, únicamente podemos tener un formulario del lado del servidor en una página
aspx.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 49
Programación II

El siguiente ejemplo es de una etiqueta <Form> típica:

<form id="Form1" method="post" runat="server">
…
</form>

Los atributos de una etiqueta <form> incluyen:

❖ method: identifica el método para enviar valores de control de retorno al servidor.
❖ Las opciones de este atributo son:
o Post. Los datos se pasan en pares nombre/valor dentro del cuerpo de la petición HTTP (Hypertext
Transfer Protocol).
o Get. Los datos se pasan en una cadena de consulta.

❖ runat: una de las principales características de un formulario Web Forms es que los controles se ejecutan
en el servidor. El atributo runat=”server” hace que el formulario publique información de control de
retorno a la página ASP.NET en el servidor donde se ejecuta el código de soporte. Si el atributo runat no
está establecido en “server”, el formulario funciona como un formulario HTML normal.

Los controles de servidor ASP.NET son componentes que se ejecutan en el servidor, éstos se utilizan en páginas
ASP.NET y en las clases de código subyacente, los controles de servidor incluyen botones, cuadros de texto y
listas desplegables, el siguiente ejemplo es el de un control de servidor Button:
<asp:Button ID="Button1" runat="server" Text="Resultado" />

Los controles de servidor tienen un atributo runat=”server”, el mismo atributo que los formularios Web Forms,
esto significa que la lógica del control se ejecuta en el servidor y no en el navegador del usuario.
Los controles de servidor se diferencian de los controles HTML en que éstos últimos únicamente se ejecutan en
el navegador del cliente y no realizan ninguna acción en el servidor.
Otra característica de los controles de servidor es que el estado de la vista, las opciones de configuración y la
entrada de datos de usuario en el control se guardan automáticamente cuando la página viaja entre el cliente y el
servidor, los controles HTML tradicionales no tienen estado y vuelven a su configuración predeterminada
cuando la página retorna del servidor al cliente.
La funcionalidad de un control es lo que se produce cuando el usuario hace clic en un botón o en un cuadro de
lista, a estos procesos se denominan procedimientos de eventos.
En ASP.NET, los controles de servidor se basan en un modelo de objetos común y, por tanto, comparten varios
atributos entre sí, por ejemplo, cuando deseamos establecer el color de fondo de un control, siempre utilizamos
el mismo atributo BackColor, independientemente del control.
El código HTML siguiente del botón de un control de servidor Web muestra algunos de los atributos típicos de
un control de servidor:
<asp:Button id="Button1" runat="server" BackColor="red" Width="238px" Height="25px" Text="Web
control"> </asp:Button>

Existen numerosos tipos de controles de servidor disponibles en ASP.NET, algunos controles de servidor se
parecen mucho a los controles HTML tradicionales, mientras que otros son nuevos en ASP.NET; esta amplia
variedad de controles nos permite personalizar nuestro formulario Web Forms para que se adapte a la aplicación
que estamos creando.
Por default, el servidor no tiene disponibles los elementos HTML de una página de un formulario Web Forms;
los elementos HTML son tratados como texto opaco que pasa a través del navegador, sin embargo, al agregar el

______________________________________________________________________________________________________________
Ciclo 01 – 2024 50
Programación II

atributo runat=”server” se convierten los elementos HTML en controles de servidor HTML, exponiéndolos por
tanto como elementos que podemos programar con código del lado del servidor.

Los controles de servidor Web se clasifican como:

➢ Controles intrínsecos. Concuerdan con los sencillos elementos HTML, como botones o cajas de listas.
Utilizamos estos controles del mismo modo que utilizamos los controles de servidor HTML.

➢ Controles de validación. Incorporan lógica que permite verificar la entrada de datos de un usuario. Para
probar la entrada de un usuario, adjuntamos un control de validación al control de entrada y
especificamos las condiciones de entrada de datos de usuario correctas.

➢ Controles ricos estándar. Los controles estándar son controles complejos que incluyen múltiples
funciones. Ejemplos incluyen el control AdRotator, que se utiliza para mostrar una secuencia de
anuncios o el control Calendar, que proporciona un calendario de citas.

➢ Controles enlazados a listas. Pueden mostrar listas de datos en una página ASP.NET. Estos controles
nos permiten mostrar, reformatear, clasificar y editar datos.

Objetos intrínsecos.
La clase Page expone varias propiedades públicas que llamaremos objetos intrínsecos.
Tres de estos objetos ya estaban disponibles antes de ASP.NET: Request, Form y Response.

Request.
El objeto Request representa a los parámetros enviados desde el navegador al servidor cuando se produce una
petición de tipo GET. En los formularios web ASP.NET, las peticiones GET se corresponden, a menudo, con
enlaces simples de hipertexto. En el caso de una petición de tipo POST (es decir, un postback en ASP.NET), el
objeto Request puede, también, incluir información de tipo parámetro: se trata de la cadena de interrogación
Query String.
Esta cadena figura en la URL tras el nombre de la página aspx. Comienza con un signo ? y está formada por una
lista de pares clave=valor separados por el símbolo &.
El siguiente extracto de código muestra cómo decodificar esta cadena:
Label1.Text = "Nombre: " + Request.QueryString["nombre"];

A pesar de la riqueza de los controles de servidor web, la cadena de interrogación sigue siendo útil para
configurar una página que se invoca tras la selección de un registro.
Consideremos, por ejemplo, la siguiente dirección:
http://localhost/ventas/articulo.aspx?id_articulo=15

Para determinar qué ficha de producto debemos presentar, la página articulo.aspx decodifica la cadena de
interrogación mediante la expresión:
Request.QueryString["id_articulo"]

El objeto Request incluye, a su vez, el conjunto de parámetros de la petición HTTP:

✓ Dirección (URL).
✓ Agente (Browser).

______________________________________________________________________________________________________________
Ciclo 01 – 2024 51
Programación II

✓ Variables de servidor (Server Variables).

✓ Tipo de contenido, en el caso del POST.

Incluso si la clase Page y los controles web tienen la potencia suficiente como para presentarnos la petición
desde un enfoque de alto nivel, el desarrollador puede contar con el objeto Request para controlar con detalle las
condiciones de ejecución de una página aspx.

Form.
La clase Page posee una propiedad Form de tipo HtmlForm que representa a la etiqueta <form>; existe un
segundo objeto Form, propiedad esta vez del objeto Request.
Este último objeto, de tipo NameValueCollection, representa los datos enviados. Con la decodificación de los
controles de servidor web existentes, es raro acceder a dicho objeto en ASP.NET, aunque siempre es una
posibilidad a la hora de construir extensiones o para mantener un formato compatible con ASP.

Response.
En ASP, el objeto Response se empleaba para escribir en el flujo de salida HTML sin tener que salir de la
programación. Este procedimiento no ha variado con ASP.NET, puesto que los controles web son capaces de
asegurar su propia visualización.
No obstante, el objeto Response sigue estando disponible para escribir otro tipo de flujo: PDF, Excel a partir de
una página aspx. Además, el objeto Response se utiliza en la gestión de la caché HTML.

Ciclo de vida de una página.

Una página dinámica aspx es un programa que se ejecuta según un proceso basado en eventos.
En la siguiente figura, vemos este proceso a grandes rasgos:

______________________________________________________________________________________________________________
Ciclo 01 – 2024 52
Programación II

A continuación, describiremos brevemente el diagrama:

Inicialización de la página por el framework.

Se trata de la primera fase del proceso de ejecución de una página. El framework instancia la página e inicializa
sus controles. El ViewState se carga y, a continuación, se decodifica. Esta fase se corresponde con los eventos
FrameworkInitialize, PreInit e Init.
El desarrollador rara vez ubica su código de aplicación a este nivel, pues los controles todavía no existen.

Inicialización mediante el código de usuario.

Esta fase se corresponde con el evento OnLoad y con el método Page_Load. A diferencia de los formularios
Windows Forms, el evento OnLoad se produce tras cada petición. Por lo general, el método Page_Load también
se invoca, a menos que el valor del atributo AutoEventWireUp de la directiva <%@ Page %> tenga un valor
igual a false.
Ejemplo:
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="autoevent.aspx.cs" Inherits="autoevent" %>

public partial class autoevent : System.Web.UI.Page

{
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
Label1.Text += "Dentro de OnLoad<br>";
}

protected void Page_Load(object sender, EventArgs e)

{
// se invoca solamente si AutoEventWireUp = true
Label1.Text += "Dentro de Page_Load<br>";
}
}

Generaría el siguiente resultado:

Como Visual Studio crea formularios con el atributo AutoEventWireUp con el valor true, y genera el método
Page_Load( ), el código de usuario prácticamente siempre se ubica en este método y no en OnLoad.
El programador debe prestar atención a no ubicar todo su código en Page_Load o en OnLoad.
Por un lado, la petición no ha terminado de ser procesada, los eventos de carga y de acción llegarán más tarde,
tras la validación de los datos introducidos por el usuario. Por otro lado, el programa se volverá ineficaz o
demasiado complejo de mantener.

Validación de datos introducidos por el usuario.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 53
Programación II

ASP.NET dispone de controles integrados para controlar los datos introducidos por los usuarios, según los
formatos estándar (campos obligatorios, fechas bien formadas, números, e-mails, etc.).
Estos controles se validan, en primer lugar, mediante JavaScript. Además, el servidor de aplicaciones les aplica
una validación adicional del lado servidor. Por último, la página dispone de una propiedad IsValid para
determinar si se han realizado con éxito todas las verificaciones.

Gestión de eventos.
Los eventos son clases ubicadas en cuatro categorías que se producen en el orden siguiente:
• Eventos que se producen al inicio de un retorno de una llamada a una función JavaScript
__doPostBack().
• Eventos de cambio de ubicación en caché, a menos que la propiedad AutoPostBack no valga true.
• Eventos de cambio, tales como TextChanged o SelectedIndexChanged.
• Eventos de acción tales como Click.

El desarrollador incluye, habitualmente, controladores para cada uno de estos eventos en el archivo de código
subyacente. Al finalizar las distintas operaciones, se invocan los métodos de enlace, se fija el estado de la vista
ViewState, y se produce la visualización de la página.
Justo antes de la transformación del modelo C# en una secuencia HTML, se produce el evento PreRender: se
trata de una señal que indica que las nuevas modificaciones en el modelo C# ya no se tendrán en cuenta. A
menos que el evento Render no se controle, para ciertos tipos de controles (por ejemplo, un calendario en el que
se quiere modificar la apariencia de los días festivos), se produce la visualización en base a los valores de los
atributos y propiedades de los distintos componentes de la página.

Liberación de recursos.
Mientras el servidor web IIS dirige la página HTML al navegador, el servidor de aplicaciones libera los recursos.
La instancia de Page se destruye, todos sus campos pierden su valor y el recolector de basura (garbage
collector) recupera la memoria de forma periódica.

Identificar las peticiones de tipo postback.

El postback se corresponde con un retorno de la página después de que el usuario haya realizado alguna acción
sobre un control web de tipo botón, calendario, etc. Algunos eventos sólo se producen en este preciso instante,
pero el método de Page_Load() se invoca sistemáticamente. Para determinar si la página se ejecuta mediante un
GET HTTP (un enlace desde otra página, una dirección introducida manualmente en la barra de direcciones del
navegador) o si la petición se genera a partir de un retorno de formulario (postback), la página expone la
propiedad estática IsPostBack.
A menudo se comprueba la negación de esta propiedad para saber cuándo hay que inicializar los controles de la
página.
Ejemplo:
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
ListBox1.Items.Add("La Palma");
ListBox1.Items.Add("Izalco");
ListBox1.Items.Add("El Zonte");

______________________________________________________________________________________________________________
Ciclo 01 – 2024 54
Programación II

}
}

Sin esta precaución, la lista ListBox1 se incrementaría de tres en tres ítems tras cada ejecución de la página.

Estado de una página ASP.NET.

HTTP es un protocolo sin estado; esto es, cada petición es tratada de forma independiente por el servidor. Esto
es así porque las páginas web se vuelven a crear cada vez que la página se envía al servidor, lo que se traduce en
que toda la información asociada a la página y a los controles de la misma se pierde con cada recorrido de ida y
vuelta.
Por lo tanto, el servidor no sabe si una serie de peticiones provienen del mismo o de diferentes clientes web y si,
además, están relacionadas entre sí. Esto presenta un sinfín de problemas para determinadas aplicaciones. Por
ejemplo, cuando estemos haciendo una compra a través de una página web y añadamos uno y otro artículo a
nuestro carrito, entre petición y petición, ¿cómo recordará el servidor lo que hemos comprado? ¿Cómo
identificará mi compra de la de otro cliente? Igualmente, cuando realicemos otra petición, por ejemplo, al
servicio que nos permite dar nuestro número de tarjeta de crédito y la dirección de envío, ¿cómo recordará el
servidor lo que hemos comprado?

Sesiones.
La conexión que se establece entre un usuario (el equipo cliente) y un servidor Web se denomina sesión.
Las sesiones pueden abarcar múltiples páginas Web y su seguimiento se realiza mediante la administración del
estado.
La administración del estado es el proceso por el cual mantenemos la misma información a través de múltiples
peticiones para las mismas o distintas páginas Web.
Al igual que las tecnologías basadas en Hypertext Transfer Protocol (HTTP), los formularios Web Forms no
tienen estado, lo que significa que no indican automáticamente si las peticiones de una secuencia son todas del
mismo cliente, ni si una única instancia de navegador sigue visualizando de forma activa una página Web o un
sitio Web, además, las páginas Web se destruyen y vuelven a crearse a continuación con cada nueva petición al
servidor Web; por tanto, la información de las páginas no existe más allá del ciclo de vida de una única página.
ASP.NET ofrece una administración del estado que guarda información en el servidor entre páginas, que ayuda a
mantener la continuidad de la información del usuario (estado) durante una visita a un sitio Web.
Si se mantiene el estado entre páginas, la información suministrada originalmente por los usuarios puede ser
reutilizada; por ello, los usuarios no necesitan volver a introducir la misma información varias veces, cada vez
que se envía una página de retorno al servidor.
Por ejemplo, un usuario puede introducir sus datos personales en un formulario, esa información se envía al
servidor y se debe mostrar en la página siguiente, sin administración del estado, la información que el usuario ha
introducido en la primera página se perdería y no se podría ver en la segunda página, sin embargo, si se utiliza
administración del estado en la aplicación Web, puede mantenerse el estado a través de varias páginas Web, por
tanto, cuando la información personal del usuario se envía al servidor, la segunda página puede conocer los datos
que el usuario introdujo en la primera página de la aplicación Web.
Para superar esta limitación inherente a la programación web tradicional, ASP.NET incluye diversas opciones
para administrar el estado de una página. Por ejemplo, incluye un servicio denominado estado de vista, que
conserva automáticamente los valores de las propiedades de la página y de todos sus controles entre un recorrido
de ida y vuelta y otro.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 55
Programación II

Otras opciones, como una cookie o un campo oculto en una página, nos permitirán guardar valores específicos
de la aplicación.
Algunas opciones mantienen la información en el cliente y otras en el servidor, según veremos a continuación.

Administración de estado en el cliente.

Las opciones cookies, cadenas de consulta, campos de formulario ocultos y estado de la vista almacenan la
información de estado en la página o en el equipo cliente; esto es, no se conserva en el servidor entre acciones de
ida y vuelta.

Cookies.
Una cookie es una pequeña cantidad de información (no más de 4 K) que una aplicación web puede crear y
almacenar en la máquina cliente y, posteriormente, consultar a través de la API de cookies de ASP.NET.
Las cookies son una de las soluciones más utilizadas para realizar el seguimiento de una sesión. Utilizando este
mecanismo, el servidor web envía una cookie al cliente (por ejemplo, con un identificador de sesión), la cual
será retornada sin modificar por el cliente automáticamente por cada nueva petición que este haga al servidor,
asociando la petición del servicio de modo inequívoco con una sesión.
En el caso del carrito de la compra, podemos utilizar cookies para almacenar el identificador del cliente para
poder identificar en el servidor los artículos comprados por este; de esta forma, cada petición subsiguiente podrá
obtener información de la anterior. Ésta es una excelente alternativa, pero, a pesar de que ASP.NET proporciona
la clase HttpCookie del espacio de nombres System.Web para que podamos trabajar con cookies, existen ciertos
aspectos que deben ser controlados y que no resultan sencillos:
▪ Extraer la cookie que almacena el identificador de sesión entre todas las cookies, ya que puede haber
varias.
▪ Seleccionar un tiempo de expiración apropiado para la cookie.
▪ Asociar la información del servidor con el identificador de sesión (cierta información que puede ser
peligrosamente manipulada, como los números de las tarjetas de crédito, nunca debe almacenarse en
cookies).

Una cookie se compone de dos partes: un nombre y un valor; el nombre la identifica entre todas las demás
cookies almacenadas en el cliente y el valor es un dato asociado con la cookie.
Una aplicación para crear una cookie simplemente tiene que invocar al constructor de la clase HttpCookie
pasando como argumentos su nombre y, opcionalmente, el valor asociado:
HttpCookie miCookie = new HttpCookie("nombre", "valor");

Una vez creada una cookie en el servidor, debe añadirse a las cabeceras de la respuesta HTTP para que sea
enviada al cliente. Para ello, hay que invocar al método Add de la colección Cookies de HttpResponse pasando
como argumento la cookie que se desea añadir:
Response.Cookies.Add(miCookie);

El método Add de Cookies no afecta a las cookies que ya existan en el cliente. El tamaño de una cookie está
limitado a 4 Kb y la mayoría de los exploradores limitan el espacio total de almacenamiento a 2 Mb, por lo que
este método puede hacer que se eliminen otras cookies. La fecha de expiración de una cookie es solo una
sugerencia; es el explorador el que decide cuándo eliminar las cookies dependiendo del espacio de
almacenamiento.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 56
Programación II

Por otra parte, la colección Cookies de HttpRequest contiene las cookies transmitidas por el cliente al servidor
en el encabezado HTTP. Entonces, para leer una cookie, hay que acceder a esa colección y localizarla.
El siguiente ejemplo recorre la colección de cookies enviadas por el cliente, y envía el nombre, el valor, la fecha
de caducidad y el parámetro de seguridad, a la salida HTTP:
private HttpCookie unaCookie = null;
// ...

for (int i = 0; i < this.Request.Cookies.Count; i++)

{
unaCookie = this.Request.Cookies[i];
Response.Write("Nombre: " + unaCookie.Name + "<br>");
Response.Write("Valor: " + unaCookie.Value + "<br>");
Response.Write("Expira: " + unaCookie.Expires + "<br>");
Response.Write("Seguridad: " + unaCookie.Secure + "<br>");
}

Cuando un cliente realiza una petición a un servidor, envía las cookies propias de ese servidor, no todas. Las
cookies que un cliente almacena para un servidor solo pueden ser devueltas a ese mismo servidor. Por lo tanto,
las aplicaciones que se ejecutan dentro de un servidor comparten las cookies.
El siguiente ejemplo muestra una página que escribe una cookie para llevar la cuenta del número de veces que es
accedida:
private HttpCookie miCookie;

protected void Page_Load(object sender, EventArgs e)

{
// Obtener el valor actual de la cookie "cuenta" buscando
// entre las cookies recibidas.
miCookie = null;
for (int i = 0; i <= this.Request.Cookies.Count - 1; i++)
{
miCookie = this.Request.Cookies[i];
if (miCookie.Name == "cuenta") break;
}
}

protected void BtnPrueba_Click(object sender, EventArgs e)

{
/* Incrementar el contador para esta página. El valor es guardado en la cookie con
el nombre "cuenta".
Después, asegurarse de enviársela al cliente con la respuesta (Response).*/
if (miCookie == null)
{
// Si no se encontró
miCookie = new HttpCookie("cuenta", "1");
}
else
{
// Si se encontró
miCookie.Value = Convert.ToString(Convert.ToInt32(miCookie.Value) + 1);
}

______________________________________________________________________________________________________________
Ciclo 01 – 2024 57
Programación II

this.Response.Cookies.Add(miCookie);

// Mostrar el resultado en la página

Label2.Text = TxtNombre.Text + " has visitado esta página " + miCookie.Value;
}

Estado de vista.
Se conoce como estado de vista al método que utiliza una página web ASP.NET para conservar los valores de
sus propiedades y de las propiedades de sus controles, entre los recorridos de ida y vuelta que se producen
cuando se solicita la misma repetidas veces. También se pueden almacenar parejas atributo-valor.
Para guardar este estado se utiliza la propiedad ViewState que los controles heredan de la clase Control del
espacio de nombres System.Web.UI. Esta propiedad proporciona un diccionario (un objeto colección) para
conservar valores entre las distintas peticiones de una misma página.
Internamente, el estado de vista se define mediante un campo oculto incluido en el formulario HTML
correspondiente a la página. Este campo oculto, denominado __VIEWSTATE, es añadido por el servidor a cada
formulario que especifique el atributo runat=“server”. De esta forma, es la página web la que se encarga, de
forma transparente al usuario, de mantener su estado que será actualizado en el servidor.
La página genera este campo durante la generación del HTML, es decir, en el último momento posible en el que
la información está disponible.
Esto lo podemos comprobar fácilmente si visualizamos el código fuente de la página HTML que se muestra en el
explorador web de la máquina cliente.
En él podemos ver algo así:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/w
EPDwULLTE1MzI4NTE1OTYPFgIeBmN1ZW50YQUCMTUWAgIDD2QWBAIHDw8WAh4EVGV4dAURQmllbnZlbmlkbyBKYXZpZXJ
kZAIJDw8WAh8BBSpWaXNpdGFzIGEgZXN0YSBww6FnaW5hIGVuIGVzdGEgc2VzacOzbjogMTVkZGSvWLBUDBJdwwWSRcwQ
7XeyEkEvbw=="/>

El valor de __VIEWSTATE representa el estado de la página la última vez que se procesó en el servidor y,
aunque se envía al cliente, no contiene ninguna información que deba utilizar el cliente. La información que se
almacena en el estado de vista solo concierne a la página y a algunos de sus controles secundarios, y la lee,
utiliza y modifica exclusivamente el servidor.
El siguiente ejemplo muestra una página que utiliza su propiedad ViewState para llevar la cuenta del número de
veces que es accedida:

public partial class WebForm1 : System.Web.UI.Page

______________________________________________________________________________________________________________
Ciclo 01 – 2024 58
Programación II

{
protected void Page_Load(object sender, EventArgs e)
{
// Usando "Estado de vista"
if (!this.IsPostBack)
if (this.ViewState.Count == 0)
this.ViewState["cuenta"] = "0";
}

protected void BtnPrueba_Click(object sender, EventArgs e)

{
Label2.Text = "Bienvenido " + TxtNombre.Text;
this.ViewState["cuenta"] =
Convert.ToString(Convert.ToInt32(this.ViewState["cuenta"]) + 1);

Label3.Text = "Visitas a esta página en esta sesión: " + this.ViewState["cuenta"];

}
}

Administración de estado en el servidor.

ASP.NET ofrece distintas maneras de conservar la información de estado en el servidor. Éstas son las siguientes:
estado de aplicación y estado de sesión.

Estado de aplicación.
El estado de aplicación es un mecanismo de almacenamiento general accesible desde todas las páginas de la
aplicación web, por lo que es útil para el almacenamiento de información que deba conservarse entre recorridos
de ida y vuelta del servidor y de una página a otra.
Este estado está definido para cada aplicación web activa por un objeto Application de la clase
HttpApplicationState. Se trata de un diccionario con elementos clave-valor que se crea cuando se resuelve una
URL específica.
Igual que ocurría con la propiedad ViewState, puede agregar información específica de la aplicación a esta
estructura para almacenarla entre las peticiones de página.
El ejercicio expuesto anteriormente puede escribirse también así:
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack)
if (this.Application.Count == 0)
this.Application["cuenta"] = "0";
}

protected void BtnPrueba_Click(object sender, EventArgs e)

{
Label2.Text = "Bienvenido " + TxtNombre.Text;
this.Application["cuenta"] =
Convert.ToString(Convert.ToInt32(this.Application["cuenta"]) + 1);

Label3.Text = "Visitas a esta página: " + this.Application["cuenta"];

}

______________________________________________________________________________________________________________
Ciclo 01 – 2024 59
Programación II

Los atributos fijados a través del objeto Application tienen ámbito de aplicación; esto quiere decir que son
visibles por todos los componentes de la capa web durante todo el período de vida de la aplicación. Esto es, si la
aplicación se desinstala o se reinicia, los atributos se pierden. Por eso, ahora el valor de la cuenta continúa de una
sesión a otra; esto es, no se reinicia en cada sesión.

Estado de sesión.
ASP.NET proporciona estado de sesión utilizando una instancia de la clase HttpSessionState para cada sesión
de aplicación Web activa, el estado de sesión es similar al estado de aplicación, salvo en que está limitado a la
sesión actual del navegador; si distintos usuarios están utilizando una aplicación Web, cada usuario tendrá un
estado de sesión distinto, además, si el mismo usuario abandona la aplicación Web y regresa más tarde, ese
usuario también tendrá un estado de sesión distinto al que tenía antes.
El estado de sesión está almacenado como una estructura de diccionario clave-valor que se utiliza para
almacenar información específica de la sesión que debe mantenerse entre transferencias de páginas al servidor y
entre peticiones de páginas.
Tras agregar la información específica de la aplicación al estado de sesión, el servidor la gestiona, podemos
configurar ASP.NET para que automáticamente serialice y almacene la información de sesión en una base de
datos SQL Server o en un servidor de estado.
Los valores que necesitan conservarse durante la sesión de un usuario se pueden almacenar en las variables de
sesión. Estas variables son únicas de cada sesión de usuario y se puede tener acceso a ellas en cualquier página
ASP.NET dentro de la aplicación. Puede establecer y tener acceso a la información de la sesión desde dentro de
la aplicación ASP.NET.
Por ejemplo:
//Asignar un valor a la variable de sesión myvariable.
Session["myvariable"] = "algúnvalor";

//Recuperar el valor de la variable de sesión myvariable.

string myString;

if (Session["myvariable"] != null)
myString = (string)Session["myvariable"];

El ejercicio expuesto anteriormente (para estado de aplicación) puede escribirse también así:
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack)
if (this.Session.Count == 0)
this.Session["cuenta"] = "0";
}

protected void BtnPrueba_Click(object sender, EventArgs e)

{
Label2.Text = "Bienvenido " + TxtNombre.Text;
this.Session["cuenta"] = Convert.ToString(Convert.ToInt32(this.Session["cuenta"]) +
1);
Label3.Text = "Visitas a esta página en esta sesión: " + this.Session["cuenta"];
}

______________________________________________________________________________________________________________
Ciclo 01 – 2024 60
Programación II

Los atributos fijados a través del objeto Session tienen ámbito de sesión, esto quiere decir que son visibles solo
por el cliente HTTP que inició la sesión, para múltiples peticiones y hasta que la sesión finalice. Esto es, si la
sesión finaliza automáticamente porque transcurrió el tiempo fijado por el servidor, si es cancelada
manualmente, o si la aplicación se desinstala o se reinicia, los atributos se pierden.

ASP.NET proporciona las variables de sesión necesarias para mantener el estado de sesión. Los datos ideales
para almacenar en las variables de estado de sesión son datos fugaces o confidenciales, específicos de una sesión
individual; con ASP.NET, el estado de sesión puede utilizarse tanto en configuraciones de múltiples equipos
como de múltiples procesos, optimizando por tanto los escenarios de escalabilidad de una aplicación Web.
Cada sesión de aplicación Web activa está identificada y monitorizada utilizando una cadena SessionID de 120
bits que únicamente contiene los caracteres ASCII permitidos en las URL’s.
Las cadenas SessionID están comunicadas a través de peticiones cliente-servidor, mediante una cookie HTTP o
mediante una URL modificada, con la cadena SessionID embebida, denominadas normalmente SessionID sin
cookies, dependiendo de la configuración de la aplicación Web.
La administración del estado en el lado del servidor requiere que una cookie almacene la SessionID en el equipo
cliente, debido a que la vida de una SessionID es muy breve, sólo lo que dura una sesión, el mecanismo que
ASP.NET utiliza para almacenar la información de sesión, en una base de datos SQL Server o en un servidor de
estado, también se utiliza para permitir que la aplicación sea escalable, pero no para un almacenamiento a largo
plazo. Si deseamos implementar el almacenamiento a largo plazo de la información de sesión del usuario,
debemos requerir a los usuarios que introduzcan su información personal, y deberemos implementar nuestra
propia solución de almacenamiento utilizando una base de datos que almacene permanentemente la información
personal de usuarios registrados.
Es importante recordar que las variables de sesión son ahora objetos. Así, para evitar que se produzca un error en
tiempo de ejecución, debe comprobar si la variable está establecida antes de intentar tener acceso a ella.
Las variables de sesión se descartan automáticamente si no se utilizan durante el tiempo de espera especificado
en el archivo Web.config. En cada solicitud se restablece el tiempo de espera. Las variables se pierden cuando la
sesión se abandona explícitamente en el código.
Cuando se inicia una sesión en la primera solicitud, el servidor emite un Id. de sesión único para el usuario. Para
conservar el Id. de sesión, almacénelo en una cookie en memoria (que es el valor predeterminado) o incrústelo
dentro de la dirección URL de la solicitud después del nombre de la aplicación. Para cambiar entre el estado de
sesión con cookies y sin cookies, establezca el valor del parámetro cookieless del archivo Web.config en true o
false.
En el modo sin cookies, el servidor inserta automáticamente el Id. de sesión sólo en las direcciones URL
relativas. Las direcciones URL absolutas no se modifican, incluso aunque señalen a la misma aplicación
ASP.NET, lo que puede provocar la pérdida de las variables de sesión.
El archivo Global.asax es un archivo declarativo que se utiliza para la gestión de eventos mientras la aplicación
Web se está ejecutando, el archivo Global.asax puede gestionar eventos de aplicación y de sesión (inicio y final)
que pueden utilizarse para inicializar variables de aplicación y de sesión.

Session_Start.
Este evento se invoca cuando se inicia la sesión de un usuario en una aplicación Web ASP.NET.

Session_End.
Este evento es un evento reciproco de Session_Start. Este evento se invoca cuando finaliza la sesión de un
usuario.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 61
Programación II

Es muy frecuente conservar para cada usuario datos de todo tipo: preferencias de presentación, criterios de
ordenación, selección de artículos, etc.
Los períodos de tiempo en los que se mantienen estos datos en la aplicación se denominan sesiones.

Uso del objeto Session.

Las sesiones es una técnica para el mantenimiento de estado. Las sesiones apenas consumen ancho de banda;
sólo 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.

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 BtnPrueba_Click(object sender, EventArgs e)
{
Session["nombre"] = TxtNombre.Text;
Response.Redirect("Pagina_Sesion.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 = "Bienvenido " + 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:
// verificación
int id_user;

if (Session["nombre"] != null)
id_user = (int)Session["nombre"];

Inicialización del objeto Session.

Como hemos mencionado anteriormente, el servidor de aplicaciones ASP.NET produce los eventos globales,
tales como Session_Start() y Session_End().
Estos eventos puede interceptarlos el programador definiendo el archivo Global.asax.
void Session_Start(object sender, EventArgs e)
{
// Este código se ejecuta cuando un usuario inicia una sesión
System.Data.DataSet ds = new System.Data.DataSet();
Session["nombre"] = ds;
}

void Session_End(object sender, EventArgs e)

{

______________________________________________________________________________________________________________
Ciclo 01 – 2024 62
Programación II

/* Este código se ejecuta cuando la sesión de un usuario falla (tras 20 segundos

de inactividad) */
System.Data.DataSet ds = Session["nombre"] as System.Data.DataSet;
}

A continuación, veremos un par de ejemplos sencillos de uso de sesiones en ASP.NET.

Ejemplo 1.
El ejemplo es una simulación sencilla de un formulario que va cargando Productos en un ArrayList, y lo envía al
servidor para almacenarlo en una variable de sesión, luego abriendo incluso otra ventana el mismo puede ser
recuperado y listado.
El diseño de la primera página debe lucir así:

Damos doble clic al botón Agregar y digitamos el siguiente código en el evento Click:
protected void BtnAgregar_Click(object sender, EventArgs e)
{
ArrayList productos;

if (Session["s_producto"] != null)
productos = (ArrayList)Session["s_producto"];
else
productos = new ArrayList();

productos.Add(this.TxtProducto.Text.ToString());

Session["s_producto"] = productos;
}

Luego, agregamos una segunda página Web Forms y le colocamos como nombre “Productos”.
En el evento Page_Load de esta página, digitamos el siguiente código:
protected void Page_Load(object sender, EventArgs e)
{
ArrayList productos = new ArrayList();

if (Session["s_producto"] != null)
{
Response.Write("Los productos en existencia son: <br/>");
productos = (ArrayList)Session["s_producto"];
foreach (string item in productos)
Response.Write(item + "<br/>");
}
else

______________________________________________________________________________________________________________
Ciclo 01 – 2024 63
Programación II

{
Response.Write("No cargó ningún producto");
}
}

Podemos probar nuestro ejemplo.

Ejemplo 2.
Crearemos un formulario de logeo en una aplicación, que si introducimos correctamente los datos nos permitirá
acceder a otra página.

Agregamos un Web Forms y le colocamos como nombre “Login”, que podría lucir como se observa en la
Figura 1.

Figura 1.

Damos doble clic al botón Login y digitamos el siguiente código en el evento Click:
protected void BtnLogin_Click(object sender, EventArgs e)
{
//leemos el contenido de cada control TextBox
string codigo = TxtCodigo.Text;
string password = TxtPassword.Text;

if (codigo == "Administrador") //si en el primer control hemos escrito "Administrador"

{
Session["logueado"] = true; // crea una variable de sesión (visible en todas las
// páginas)

Response.Redirect("Articulos.aspx"); //redireccionamos a otra página

}
else
{
LblMensaje.Text = "Datos incorrectos. Inténtenlo de nuevo por favor.";
}
}

______________________________________________________________________________________________________________
Ciclo 01 – 2024 64
Programación II

Luego, agregamos una segunda página Web Forms y le colocamos como nombre “Articulos”.
Validamos que tengamos acceso a la página (que exista una variable de sesión con el valor correcto), en otro
caso obligamos a que se logue redireccionándolo a la página de logueo.
Esta validación se tendrá que incluir en todas las páginas que queramos que no se acceda sin loguearse
previamente.

En el evento Page_Load de esta página, digitamos el siguiente código:

protected void Page_Load(object sender, EventArgs e)
{
/* IMPORTANTE. Cuando se lee una variable de sesión hay que realizar una conversión de
tipos (casting) al tipo del valor que almacena.
En este caso es un boolean por esto se hace (bool) delante de la variable de sesion */

if ((Session["logueado"] == null) || ((bool)Session["logueado"] == false))

{
Response.Redirect("Login.aspx");
}
}

Ahora podemos probar nuestro ejemplo.

______________________________________________________________________________________________________________
Ciclo 01 – 2024 65