Eventos de ciclo de vida en ASP.NET

0
54109

Eventos en ASP.NET

Las tecnologías avanzan en todos los frentes, y Microsoft
saca pecho desde hace años con su Framework .NET. Una
evolución interesante para el mundo de desarrollo en
lenguages propietarios que siempre aportan avances al mundo
tecnológico. 

Introducción

En este tutorial veremos los eventos del ciclo de vida de una
aplicación web en ASP.NET. Recordemos que ASP.NET se basa en
el concepto de Web
Form, a diferencia de las aplicaciones de escritorio (los Window Form).
Ambos tienen un ciclo de vida diferente y basan su comportamiento en
eventos, pero debemos diferenciar ambos conceptos; todo lo que sigue a
continuación es propio de los desarrollos web
el framework .NET.

Los eventos en ASP.NET se clasifican en tres grupos:

  • Eventos a nivel de aplicación. Son eventos
    globales de nuestra web,
    como pueden ser el inicio de la aplicación,
    finalización de una sesión,
    etc
  • Eventos a nivel de página. Habitualmente
    lanzados por el
    usuario, como el submit de un formulario o pulsar sobre un enlace.
  • Eventos a nivel de servidor. Son los eventos propios de los
    controles de servidor de los Web Forms

Antes de entrar en detalles, echemos un vistazo al ciclo de
vida de una
aplicación web y sus eventos principales.

Eventos en el ciclo de vida de una aplicación web

Una aplicación web inicia propiamente su existencia
cuando un cliente se conecta a su página de inicio (es el
inicio de una sesión). El servidor web Internet Information
Server (IIS) levanta el
proceso aspnet_wp.exe (en caso de ser necesario, podría
estar ya activo con el servidor dando servicio) y carga el ensamblado
DLL que contiene el
código programado de la página
solicitada y que se ejecuta en lado servidor. El servidor crea una
instancia del Web Form solicitado, lo
completa accediento a los recursos e información necesarios,
ejecuta la
lógica de negocio y emite como respuesta ese Web Form en
formato HTML al browser cliente. Tras esto, la instancia del Web Form y
sus recursos son liberados de memoria.

 

Primera
petición web de una aplicación.

El ciclo se repite: el usuario rellena un formulario HTML,
envía los datos al servidor, éste crea un Web
form, le asigna los datos enviados y procesa los eventos,
envía el Web form resultante como HTML y se libera junto con
sus recursos. Vemos cómo los el ciclo de vida de un Web Form
es muy corto.

Continua
la
navegación por la web (e.g. proceso de un formulario)

Sin embargo, la aplicación web sigue viviendo hasta
que todas las sesiones a las que está dando servicio
finalizan. Tras un tiempo sin
atender nuevos eventos en una sesión, el servidor destruye
la sesión, y cuando no queda ninguna activa, finaliza la
aplicación web (el CLR libera de memoria los recursos de la
aplicación tales como el DLL cargado) y se lanza un evento
Application_End.

No hay clientes activos:
las sesiones expiran y la
aplicación web correspondiente finaliza

Debemos aclarar que por sesión entendemos una instancia de
navegador emitiendo peticiones a un servidor. Un usuario puede tener
múltiples navegadores abiertos y por tanto
múltiples sesiones iniciadas.

Si queremos que la información persista entre las
distintas instancias volátiles y sin estado de los
Web form, podemos
hacer uso de dos niveles de ámbito en el servidor:

  • Variables a nivel de aplicación. Es un espacio
    global existente en todo el ciclo de vida de la aplicación
    web, y accesible desde todas las sesiones a las que ésta da
    servicio en un determinado momento.
  • Variables a nivel de sesión. La
    aplicación web tiene reservados tantos espacios de memoria
    reservados como sesiones tenga activas y reducidas a su
    ámbito e inaccesibles fuera de ellas (independientes entre
    sí).

Eventos de las aplicaciones y de las sesiones

Vamos a enumerar los manejadores de (métodos que
capturan) los eventos y a ponerlos en práctica con
pequeños ejemplos en C# programados con Visual Studio .NET.

La signatura de los métodos son de la forma

protected void <nombre_manejador> (Object
sender, EventArgs e)

siendo <nombre_manejador> éstos:

Manejador
de evento
Acción
asociada
Application_Start Primera visita a la página
inicio de la aplicación web
Application_BeginRequest Inicio petición al servidor
(solicitar una página)
Application_EndRequest Fin de petición al servidor
(la página ya ha sido solicitada)
Application_End Todas las sesiones de usuario expiran
Application_AuthenticateRequest Petición
de autenticación
Application_Error La
aplicación lanza un error
Session_Start Un nuevo usuario solicita una
página de la aplicación web
Session_End Un usuario deja de hacer peticiones a la
aplicación web y su tiempo de sesión expira.

Los manejadores de eventos se encuentran definidos en el
fichero del
proyecto Global.asax:

Vamos a escribir un ejemplo que cuente el número de
veces que el servidor recive eventos de un internauta como nosotros.
Para ello utilizamos los mapas que ofrece el  IIS como
variables de estado para almacenar objetos en memoria en sus
distintos ámbitos (‘Application’ para aplicación
y ‘Session’ para sesión) :

   

protected
void
Application_Start(Object sender, EventArgs e)

{

   //Initializations
os the counters at the beginning:

 
 Application[«activeApplications»]=0;

   Application[«activeSessions»]=0;


 
 //Increase the
respective event

   Application[«activeApplications»]=(int)Application[«activeApplications»]+1;

}


protected
void
Session_Start(Object sender, EventArgs e)

{

 
 //Increase the respective event

   Application[«activeSessions»]=(int)Application[«activeSessions»]+1;

   // Once in a
session, we can send text to the browser:

   Response.Write(«<p>Web
Application events:
«+Application[«activeApplications»]+»<br/>Active
sessions: «+Application[«activeSessions»]+»</p>»);

}

protected
void
Application_BeginRequest(Object sender,
EventArgs e)

{

 
 Response.Write(«<p><b>[Aplication_BeginRequest]</b>:
begin of browser request</p>»);

}

 

protected
void
Application_EndRequest(Object sender,
EventArgs e)

{

 
 Response.Write(«<p><b>[Aplication_EndRequest]</b>:
end of browser request</p>»);

}

 

protected
void
Session_End(Object sender, EventArgs e)

{

   //the
session has expired. Is this web site too boring?

    Application[«activeSessions»]=(int)Application[«activeSessions»]-1;

}

 

protected
void
Application_End(Object sender, EventArgs e)

{

 
 //no users in our web
site

 
 Application[«activeApplications»]=(int)Application[«activeApplications»]+1;

Una vez compilada la aplicación accedemos a la URL
del ejemplo:
http://localhost/eventosASPNET/events_page.aspx
y vemos algo
así:

Desde otro navegador, accedemos a la misma
aplicación web:

Y más!:

Ahora bien: dos pestañas de un misno navegador
Internet Explorer se interpretan como dos peticiones dentro de una
misma sesión (son dos instancias de un mismo browser
contenedor). Por
en la siguiente captura sólo se muestran las trazas de la
request (no se captura ningún evento de inicio de
sesión porque ésta ya la inició
la pestaña de la izquierda):

Eventos de los Web Form

Si una página la hemos programado con un Web Form,
podemos utilizar los siguientes eventos para capturar una amplia
variedad de situaciones:

Manejador de evento Acción
asociada
Page_Init El
servirdor crea una instancia del Web Form, carga sus controles y los
inicializa con lo recibido del estado de la vista (datos del browser
del cliente que vienen con la request).
Page_Load Los
controles del servidor se cargan en un nuevo objeto de tipo Page. Ahora
el programador puede acceder a la información de la vista y
manejar los controles de la página, contenido, etc.
Page_PreRender El objeto Page va a renderizarse
en código interpretable por el browser en cuanto finalice
este evento.
Page_Unload El objeto Page deja de ser
referfenciable, se destruye.
Page_Disposed La memoria ocupada por Page es liberada.
Page_Error Evento iniciado cuando se ha producido
una excepción no capturada.
Page_AbortTransaction Una operación transaccional ha
sido finalizada sin llegar a su fin.
Page_CommitTransaction La transacción se ha
completado con éxito.
Page_DataBinding Un control de servidor se ha conectado a
una fuente de datos.

Eventos de los controles de servidor

Los controles de servidor son aquellos elementos que
introducimos en
nuestros Web Forms y pueden lanzar acciones, e.g. botones, listas,
áreas de texto, etc. Si hemos trabajado antes con ellos
seguro
que nos vendrá a la mente el hecho de su variedad en
función de sus propósitos y acciones que se
permiten al
usuario. Es por esto que los eventos, concretando este razonamiento,
han sido divididos en tres grupos:

  • Eventos de envío. Son los eventos lanzados por
    controles
    que emiten un envío (post) al servidor de manera inmediata
    para
    procesar el Web Form. Por ejemplo al enviar un formulario pulsando
    sobre el botón de aceptación. Estos controles
    son:
    Button, Link Button e Image Button.
  • Eventos de caché. Estos eventos se producen en
    la vista y
    serán procesados en el servidor cuando se envíe
    la
    información mediante un evento de envío. Por
    ejemplo el
    seleccionar un elemento de una lista provoca un cambio de estado de la
    misma que luego, en servidor, podremos obtener. Controles con eventos
    de caché son TextBox, DropDownList, CheckBox…
  • Eventos de validación. Son los eventos que se
    procesan
    dentro de la página web. El ejemplo típico es la
    validación de que un campo de entrada está
    vacío o
    no cuando es obligatorio, usando capacidades de validación
    del
    propio componente.

En el ciclo de vida de un Web Form se aplica el siguiente algoritmo de
manejo de eventos:

  1. Los controles con validación hacen las
    validaciones en el
    propio cliente antes de que la página sea enviada al
    servidor
    (se ha tenido que producir un evento de envío previamente).
  2. La página se envía y se suceden los
    eventos
    Page_Init y Page_Load. Se procesan los eventos cacheados por orden
    temporal y finalmente se procesa el evento de envío.
  3. Nuestra lógica de negocio realiza las acciones
    pertinentes con los controles.

Orden de los eventos de
los controles de servidor; 1º:
validación, 2º: cache, 3º:
envío.

Vamos a utilizar los eventos de Web Form y de controles en
otro ejemplo. Conforme a la imagen anterior, tenemos un Web Form con
dos campos de texto Nombre y Apellidos. Ambos son obligatorios y
decidimos controlarlo en la propia página (con un
componente RequiredFieldValidator). Una vez todo es correcto, se hace
la request y en servidor mostramos la secuencia de manejo de eventos.

La primera imagen muestra una pulsación del
botón Enviar con los campos obligatorios vacíos.
el propio navegador gestiona los eventos de validación y se
omite la request:

Lo mismo ocurre si dejamos un campo vacío y
pretendemos hacer el envío:

Finalmente introducimos los dos campos y obtenemos por
pantalla el orden por el que el sevidor maneja los eventos del Web Form:

El código para
esto es simple y se aloja en la clase C# events_page.aspx.cs asociado
al Web Form events_page.aspx:

private void btnEnviar_Click(object
sender, System.EventArgs e)

{

    Response.Write(«[Servidor] Procesando
evento pulsación de botón
\»Enviar\»<br/>\n»);

}

private void
txtNombre_TextChanged(object
sender,
System.EventArgs e)

{

   Response.Write(«[Servidor] Procesando
evento de cambio de texto en el campo \»Nombre\»<br/>\n»);

}

private void
txtApellidos_TextChanged(object
sender, System.EventArgs e)

{

    Response.Write(«[Servidor] Procesando
evento de cambio de texto en el campo
\»Apellidos\»<br/>\n»);

}

Conclusiones

Un buen desarrollo web con .NET comienza dominando la
teoría
de los eventos de nuestra aplicación, saber cuales son,
donde se
procesan y cómo podemos manejarlos en nuestra
lógica
programada. Los eventos son la interfaz
aplicación/programador
que permiten desarrollos rápidos de aplicaciones,
característica esencial del framework .NET.

En Autentia no dejamos de lado estas
tecnologías; las estudiamos, las aplicamos a nuestros
proyectos y, como siempre, compartimos la información
con vosotros. Deseamos que esto resulte útil para
favorecer el desarrollo de software con calidad.

Dejar respuesta

Please enter your comment!
Please enter your name here