1

Procesamiento de páginas de formularios

Web Forms

En general, el ciclo de vida de una página de formularios Web Forms es similar al de cualquier proceso Web que se ejecuta en el servidor. Algunas características de procesamiento Web, como la información pasada a través del protocolo HTTP, el hecho de que las páginas Web no tengan estado, etc., se aplican a las páginas de formularios Web Forms de la misma forma que a la mayoría de aplicaciones Web.

Sin embargo, el marco de trabajo de página ASP.NET realiza por sí sola muchos servicios de aplicación Web. Por ejemplo, el marco de trabajo de página ASP.NET captura la información enviada con la página de formularios Web Forms, extrae los valores importantes y hace que la información sea accesible a través de las propiedades del objeto.

Es importante entender la secuencia de eventos que tiene lugar cuando se procesa una página de formularios Web Forms. Este conocimiento le ayudará a programar sus páginas de formularios Web Forms y aplicaciones Web de manera más eficiente.

El ciclo de vida de una página de formularios Web

Forms

Puede serle útil comprender ciertas características fundamentales sobre cómo trabajan las páginas de formularios Web Forms en las aplicaciones Web antes de examinar los detalles de lo que sucede en una página cuando ésta se procesa.

Acciones de ida y vuelta

Uno de los conceptos principales que debe comprender es la división del trabajo en una página de formularios Web Forms. El explorador presenta el formulario al usuario y éste interactúa con él, causando que el formulario se envíe de vuelta al servidor. Sin embargo, como todo procesamiento que interactúa con componentes de servidor debe ocurrir en el servidor, esto significa que, para cada acción que necesita procesamiento, el formulario debe enviarse al servidor, procesarse y ser devuelto al explorador. Esta secuencia de eventos se conoce con el nombre de acción de ida y vuelta.

Nota Puede crear una secuencia de comandos de cliente en formularios Web Forms, que puede serle útil para validar la introducción de datos por el usuario y para algunos tipos de programación de UI. La secuencia de comandos de cliente no interactúa con los componentes de servidor.

Imagine un escenario empresarial: un usuario introduce un pedido y usted desea confirmar si existe inventario suficiente para el pedido, por lo que su aplicación envía la página al servidor en un punto determinado del proceso de entrada del pedido del usuario. Un proceso de servidor examina el pedido, realiza una búsqueda en el inventario, quizás realice alguna acción definida en la lógica de negocio (como modificar la página para indicar un error) y devuelve la página al explorador para que el usuario continúe.

Acción de ida y vuelta

2

En los formularios Web Forms, la mayoría de las acciones del usuario, como hacer clic en un botón, dan como resultado una acción de ida y vuelta. Por dicha razón, los eventos disponibles en los controles de servidor ASP.NET suelen limitarse a eventos de tipo clic. La mayoría de los controles de servidor exponen un evento Click, que requiere una respuesta explícita del usuario.

Por la misma razón, los controles de servidor no exponen eventos que se producen con mucha frecuencia, como, por ejemplo, onmouseover, porque cada vez que se produce un evento, ocurre una nueva acción de ida y vuelta al servidor, lo que afecta considerablemente al tiempo de respuesta del formulario.

Volver a crear la página (estado de vista y administración de estado)

En cualquier escenario Web, las páginas se vuelven a crear con cada acción de ida y vuelta. Tan pronto como el servidor termina de procesar y enviar la página al explorador, descarta la información de la página. Mediante la liberación de recursos de servidor después de cada petición, se puede ajustar una aplicación Web para que admita cientos o miles de usuarios simultáneos. La siguiente vez que se envía la página, el servidor empieza a crearla y procesarla y, por esta razón, se dice que las páginas Web no tiene estado, ya que los valores de las variables y controles de una página no se conservan en el servidor.

Nota Se puede configurar el servidor para que almacene la información de la página en la memoria caché y así optimizar las páginas, pero para el objetivo de la programación de aplicaciones, es mejor pensar que se eliminan tan pronto como el servidor ha terminado de procesarlas.

En una aplicación Web tradicional, la única información que tiene el servidor sobre el formulario es aquella que ha agregado el usuario a los controles del formulario, porque dicha información es enviada al servidor con el formulario. Cualquier otro tipo de información, como los valores de las variables y la configuración de las propiedades, se elimina.

ASP.NET soluciona estas limitaciones de las siguientes formas:

3

• Guarda la página y las propiedades de los controles entre las acciones de ida y vuelta. Esto se conoce como guardar el estado de vista del control.

• Proporciona servicios de administración de estado para que pueda guardar su propia información sobre las variables e información específica de la aplicación o de la sesión entre acciones de ida y vuelta.

• Puede detectar cuándo es pedido un formulario por primera vez y cuándo es enviado, lo que le permite programar de manera conveniente. Puede desear un comportamiento diferente durante la devolución de datos de la página y durante la petición inicial.

Ventajas de un modelo orientado a eventos contra un modelo de

procesamiento lineal

Si ya tiene experiencia en el uso de ASP (Active Server Pages, páginas Active Server), sabrá que ASP es un modelo de programación lineal. Una página ASP se procesa en una secuencia de arriba abajo. Cada línea de código ASP y HTML estático se procesa en secuencia tal y como aparece en el archivo. Las acciones del usuario hacen que la página se envíe al servidor en una acción de ida y vuelta. Por esta razón, el servidor debe volver a crear la página. Una vez que la página se ha creado de nuevo, se procesa en la misma secuencia de arriba abajo anterior. Por lo tanto, la página no muestra un comportamiento real de orientación a eventos. Para que esté orientada a eventos, es necesario diseñarla explícitamente. Además, tiene que mantener explícitamente el estado de la página y de los controles al más bajo nivel. Este modelo limita la riqueza de las interfaces de usuario que se pueden ensamblar y aumenta la complejidad del código.

En comparación, un modelo orientado a eventos, como es el caso de una aplicación de Visual Basic tradicional, contiene elementos programables que se inicializan y se muestran en el formulario. El usuario interactúa con los elementos, lo que produce eventos que, por turnos, llaman a los controladores de eventos. Este modelo admite un comportamiento real de orientación a objetos que, mediante diseño, aumenta la riqueza de las interfaces de usuario que se pueden ensamblar y reduce la complejidad del código.

ASP.NET reemplaza el modelo de procesamiento lineal de ASP emulando el comportamiento de un modelo orientado a eventos. El marco de trabajo de página ASP.NET sirve para realizar implícitamente las asociaciones de un evento a un controlador de evento. Mediante el marco de trabajo de páginas se puede crear fácilmente una interfaz de usuario que reaccione a las acciones del usuario. Para obtener información detallada sobre la creación y utilización de eventos y controladores de eventos, vea Control de eventos de servidor en páginas de formularios Web Forms.

Adicionalmente, este mismo marco de trabajo facilita la implementación de la administración de estado de la página y los controles. Para obtener más información sobre la administración de estado, vea Administración del estado de los formularios Web Forms.

Por ejemplo, ASP.NET le permite configurar controladores de eventos en el código de servidor para los eventos que se pasan desde el explorador. Imagine que el usuario está interactuando con una página de formularios Web Forms que contiene un único control de servidor de botón. El usuario hace clic en el control de botón y se produce un evento que se transmite al servidor mediante un envío HTTP, donde el marco de trabajo de página ASP.NET interpreta la información enviada y asocia el evento producido a un controlador de evento apropiado. Este controlador de evento puede ser un controlador predeterminado proporcionado por ASP.NET o una implementación personalizada. El marco de trabajo llama automáticamente al controlador de evento correspondiente al botón como parte del procesamiento normal del marco de trabajo. Como resultado, ya no necesita diseñar explícitamente un comportamiento orientado a eventos en un modelo de procesamiento lineal. Para obtener más información sobre el control de eventos en formularios Web Forms, vea Modelo de eventos de controles de servidor ASP.NET.

Fases del procesamiento de formularios Web Forms

4

El marco de trabajo de página ASP.NET procesa las páginas de formularios Web Forms en distintas fases. Durante cada fase del procesamiento de formularios Web Forms, se pueden producir eventos, por lo que se ejecutará el controlador de evento correspondiente. Dichos métodos le proporcionan puntos de entrada, enlaces, que le permiten actualizar el contenido de la página de formularios Web Forms.

La tabla siguiente muestra una lista de las fases más comunes del procesamiento de página, los eventos que se producen y los usos más frecuentes de cada fase. Estas fases se repiten cada vez que se solicita o se envía el formulario. La propiedad Page.IsPostBack le permite probar si la página está siendo procesada por primera vez.

Nota Existen más fases de procesamiento de una página de formularios Web Forms que las que aparecen en la lista siguiente. Sin embargo, no se utilizan en la mayoría de los escenarios de procesamiento de páginas. Las usan fundamentalmente los controles de servidor de la página de formularios Web Forms para tareas de inicialización y procesamiento. Si intenta escribir sus propios controles de servidor ASP.NET, necesitará un conocimiento más profundo de dichas fases. Para obtener información detallada acerca de todas las fases de procesamiento de páginas, vea Programar controles de servidor de ASP.NET.

Fase Significado Usos típicos

Inicialización del marco de trabajo de página ASP.NET

Se produce el evento Page_Init de la página y se restaura el estado de vista de la página y los controles.

Durante este evento, el marco de trabajo de página ASP.NET restaura las propiedades de los controles y de los datos devueltos.

Inicialización del código de usuario

Se produce el evento Page_Load de la página.

Leer y restaurar valores almacenados previamente:

• Usar la propiedad Page.IsPostBack para comprobar si es la primera vez que se procesa la página.

• Si es la primera vez, realizar enlace de datos inicial.

• Si no, restaurar los valores de los controles.

• Leer y actualizar las propiedades de los controles.

Validación El método Validate de cualquier control de servidor Web de validación permite ejecutar la validación especificada del control.

(En esta fase no existe ningún enlace de usuario. Puede probar el resultado de la validación en un controlador de evento).

Control de eventos En esta fase, si la página fue llamada en respuesta a un evento del formulario, se llama al controlador de evento correspondiente.

Realizar el procesamiento específico de la aplicación:

• Controlar el evento producido.

Nota Los eventos no se producen en un orden concreto, exceptuando los eventos de controles almacenados en memoria caché, que se especifican en la propiedad AutoPostBack del control y que siempre se

5

Fase Significado Usos típicos

procesan antes de enviar el evento.

• Si la página contiene Tipos de validación Tipos de validación para controles de servidor ASP.NET, comprobar la propiedad IsValid de la página y de cada control de validación.

• Guardar de forma manual el estado de las variables de la página que está manteniendo usted mismo.

• Compruebe la propiedad IsValid de la página o de los controles de validación individuales.

• Guardar de forma manual el estado de los controles que se agregan dinámicamente a la página.

Limpieza Se llama al evento Page_Unload porque la página ha terminado de procesarse y está lista para ser eliminada.

Realizar el trabajo de limpieza final:

• Cerrar archivos. • Cerrar conexiones a bases de datos. • Eliminar objetos.

Nota Es importante que los recursos caros, como las conexiones de base de datos, se cierren explícitamente. En caso contrario, se mantendrán abiertas hasta que ocurra la siguiente recolección de elementos no utilizados. En un servidor muy cargado, el hecho de tener muchos recursos abiertos puede afectar al rendimiento.

Recomendaciones de administración de

estado

La administración de estado es el proceso por el cual se conserva el estado y la información de la página a través de múltiples peticiones de la misma página o de páginas diferentes. Al igual que la tecnología basada en HTTP, los formularios Web Forms no tienen estado, lo que significa que no indican de manera automática si todas las peticiones que se realizan en secuencia provienen del mismo cliente ni si una instancia del explorador todavía está viendo una página o un sitio de manera activa. Además, las páginas se destruyen y se vuelven a crear con cada acción de ida y vuelta al servidor, lo que significa que la información de una página no se conservará fuera del ciclo de vida de la página. Para obtener más información sobre los recorridos de

6

ida y vuelta al servidor y el ciclo de vida de las páginas de formularios Web Forms, vea Procesamiento de páginas de formularios Web Forms.

ASP.NET ofrece distintas maneras de conservar el estado entre acciones de ida y vuelta al servidor. La selección de una de las opciones de administración de estado disponibles en ASP.NET dependerá fundamentalmente de la aplicación y debería basarse en los siguientes criterios:

• ¿Qué cantidad de información debería almacenar? • ¿El cliente aceptará cookies persistentes o en memoria? • ¿Desea almacenar la información en el cliente o en el servidor? • ¿Se trata de información confidencial? • ¿Qué tipo de criterios de rendimiento tiene para la aplicación?

ASP.NET es compatible con varias opciones de administración de estado en el cliente y en el servidor.

Las opciones en el cliente son:

• Propiedad ViewState • Campos ocultos • Cookies • Cadenas de consulta

Las opciones en el servidor son:

• Estado de aplicación • Estado de sesión • Base de datos

Opciones de administración de estado en el cliente

Las opciones en el cliente para almacenar la información de página no utilizan recursos de servidor. Estas opciones ofrecen poca seguridad pero un rendimiento rápido del servidor porque la demanda de recursos de servidor es pequeña. Sin embargo, puesto que se debe enviar información al cliente para su almacenamiento, existe un límite práctico para la información que puede almacenarse de esta forma.

Estado de la vista

Las páginas de formularios Web Forms proporcionan la propiedad ViewState como una estructura integrada para conservar automáticamente valores entre varias peticiones de una misma página. El estado de vista se mantiene en la página en forma de campo oculto. Para obtener más información, vea Introducción a la administración del estado de formularios Web Forms.

Puede utilizar el estado de vista para almacenar los valores específicos de su propia página entre recorridos de ida y vuelta, cuando la página se envía de nuevo a sí misma. Por ejemplo, si la aplicación mantiene información específica del usuario (es decir, información utilizada en la página pero que no forma parte necesariamente de ningún control), se puede almacenar en el estado de vista.

Las ventajas de utilizar el estado de vista son:

• No se necesitan recursos de servidor. El estado de vista está dentro de una estructura del código de la página.

7

• Implementación sencilla. • Retención automática del estado de la página y de los controles. • Funciones de seguridad ampliadas. Los valores de estado de vista se trocean, comprimen y codifican

para implementaciones de Unicode, lo que representa un mayor nivel de seguridad que el de los simples campos ocultos.

Las desventajas de utilizar el estado de vista son:

• Rendimiento. Puesto que el estado de vista se almacena en la propia página, el almacenamiento de valores de gran tamaño puede hacer que la página se muestre y se envíe de forma más lenta para los usuarios.

• Seguridad. El estado de vista se almacena en la página en forma de campo oculto. Aunque el estado de vista almacena los datos troceados, se puede manipular. Se puede ver la información de un campo oculto si se obtiene acceso al código fuente de la página directamente, lo que supone un problema de seguridad potencial. Para obtener más información, vea Introducción a la seguridad de aplicaciones Web..

Para obtener más información sobre cómo utilizar el estado de vista, vea Guardar valores de páginas de formularios Web Forms mediante el estado de vista.

Campos ocultos

Puede almacenar información específica de una página en un campo oculto de la página como forma de conservar el estado de la misma. Para obtener más información sobre campos ocultos, vea Introducción a la administración del estado de formularios Web Forms.

Si utiliza campos ocultos, es mejor almacenar sólo cantidades pequeñas de datos que cambian con frecuencia en el cliente. El control HtmlInputHidden de ASP.NET le ofrece la funcionalidad de campo oculto. Para obtener más información acerca de HtmlInputHidden, vea Controles de servidor ASP.NET por función.

Nota Si utiliza campos ocultos, deberá enviar las páginas al servidor mediante el método POST de HTTP, en lugar de solicitar la página mediante su URL (es decir, mediante el método GET de HTTP).

Las ventajas de utilizar campos ocultos son:

• No se necesitan recursos de servidor. El campo oculto se almacena y se lee en la página. • Compatibilidad amplia. La mayoría de los exploradores y dispositivos de cliente admiten formularios

con campos ocultos. • Implementación sencilla.

Las desventajas de utilizar campos ocultos son:

• Seguridad. Los campos ocultos se pueden alterar. Se puede ver la información de un campo oculto si se obtiene acceso al código fuente de la página directamente, lo que supone un problema de seguridad potencial. Para obtener más información, vea Introducción a la seguridad de aplicaciones Web..

• Estructura de almacenamiento limitada. El campo oculto no admite grandes estructuras. Los campos ocultos sólo ofrecen un campo de valor donde colocar la información. Para almacenar múltiples valores, debe implementar cadenas delimitadas y que el código analice estas cadenas.

• Rendimiento. Puesto que los campos ocultos se almacenan en la propia página, el almacenamiento de valores de gran tamaño puede hacer que la página se muestre y se envíe de forma más lenta para los usuarios.

8

Cookies

Las cookies son útiles para almacenar pequeñas cantidades de información que cambia con frecuencia en el cliente. La información se envía al servidor con la petición.

Las ventajas de utilizar cookies son:

• No se necesitan recursos de servidor. La cookie se almacena en el cliente y es leída por el servidor después del envío.

• Simplicidad. Una cookie es una estructura ligera y basada en texto con simples pares clave-valor. • La caducidad se puede configurar. La cookie puede caducar cuando se cierre la sesión del explorador

o puede existir indefinidamente en el equipo cliente, sujeta a las reglas de caducidad del mismo.

Las desventajas de utilizar cookies son:

• Tamaño limitado. La mayoría de los exploradores tienen un límite de 4096 bytes para el tamaño de cookie, aunque cada vez es más frecuente que las nuevas versiones de exploradores y dispositivos de cliente disponibles actualmente admitan un tamaño de cookie de 8192 bytes.

• El usuario puede configurar el rechazo de cookies. Algunos usuarios desactivan la capacidad de recibir cookies de su explorador o dispositivo cliente, limitando así esta funcionalidad.

• Seguridad. Las cookies se pueden alterar. Los usuarios pueden manipular las cookies en el equipo, lo que potencialmente puede influir en la seguridad o hacer que la aplicación que depende de la cookie falle. Para obtener más información, vea Introducción a la seguridad de aplicaciones Web.

• Durabilidad. La durabilidad de una cookie en un equipo cliente está sujeta a los procesos de caducidad de cookies del cliente y a la intervención del usuario.

Nota Las cookies se utilizan a menudo para tareas de personalización, donde el contenido se personaliza para cada usuario. En la mayoría de estos casos, el objetivo es más de identificación que de autenticación, por lo que es suficiente almacenar en la cookie el nombre de usuario, el nombre de cuenta o un identificador de usuario único (como un GUID) y utilizarlo para tener acceso a la infraestructura de personalización de usuario de un sitio.

Para obtener detalles acerca de la creación y lectura de cookies, vea HttpResponse.Cookies (Propiedad) y HttpRequest.Cookies (Propiedad).

Cadenas de consulta

Una cadena de consulta es información que se anexa al final de la dirección URL de una página. Para obtener más información, vea Introducción a la administración del estado de formularios Web Forms.

Puede utilizar una cadena de consulta para enviar datos de vuelta a la página o a otra página a través de la dirección URL. Las cadenas de consulta proporcionan una manera sencilla pero limitada de mantener cierta información de estado. Por ejemplo, es una manera sencilla de pasar información de una página a otra, por ejemplo, pasar un código de producto de una página a otra donde se procesará.

Nota Las cadenas de consulta sólo son viables cuando se hace una petición de la página mediante su dirección URL. No puede leer la cadena de consulta de una página cuando ésta ya se ha enviado al servidor.

Las ventajas de utilizar cadenas de consulta son:

9

• No se necesitan recursos de servidor. La cadena de consulta está dentro de la petición HTTP de una dirección URL específica.

• Compatibilidad amplia. Casi todos los exploradores y dispositivos de cliente admiten el paso de valores en una cadena de consulta.

• Implementación sencilla. ASP.NET es totalmente compatible con el método de cadenas de consulta, incluyendo métodos para leer cadenas de consulta mediante la propiedad HttpRequest.Params.

Las desventajas de utilizar cadenas de consulta son:

• Seguridad. El usuario puede ver directamente la información de una cadena de consulta en la interfaz de usuario del explorador. Las cadenas de consulta están expuestas en Internet a través de la dirección URL, lo que en algunos casos puede afectar a la seguridad. Para obtener más información, vea Introducción a la seguridad de aplicaciones Web.

• Capacidad limitada. En la mayoría de los exploradores y dispositivos de cliente la longitud de la dirección URL tiene una limitación de 255 caracteres.

Resumen de los métodos de administración de estado en el cliente

En la tabla siguiente se resumen las opciones de administración de estado del cliente y cuándo se debe considerar su uso.

Método Utilícelo cuando

Estado de vista Necesite almacenar cantidades pequeñas de información de una página que será enviada de vuelta. El uso de la propiedad ViewState proporciona funcionalidad con una seguridad básica.

Campos ocultos Necesite almacenar cantidades pequeñas de información de una página que será enviada de vuelta o de otra página y la seguridad no sea un problema.

Nota Sólo puede utilizar campos ocultos en páginas que se envíen al servidor.

Cookies Necesite almacenar cantidades pequeñas de información en el cliente y la seguridad no sea un problema.

Cadena de consulta Transfiera cantidades pequeñas de información de una página a otra y la seguridad no sea un problema.

Nota Sólo puede utilizar cadenas de consulta cuando hace una petición de la misma página o de otra página a través de un vínculo.

Opciones de administración de estado en el servidor

Las opciones para almacenar información de la página en el servidor suelen proporcionar un mayor nivel de seguridad que las opciones en el cliente, pero pueden utilizar mayor número de recursos de servidor Web, lo que puede afectar a la escalabilidad cuando el tamaño de la información almacenada es grande. ASP.NET proporciona distintas opciones para implementar la administración de estado en el servidor. Para obtener más información, vea Introducción a la administración del estado de formularios Web Forms.

Estado de aplicación

ASP.NET proporciona el estado de la aplicación mediante la clase HttpApplicationState, como método para almacenar información global específica de la aplicación de forma que sea visible para toda la aplicación. Las

10

variables de estado de la aplicación son variables globales de una aplicación ASP.NET. Para obtener más información, vea Estado de la aplicación.

Se pueden almacenar los valores específicos de la aplicación en el estado de aplicación, que administra el servidor. Para obtener más información, vea Introducción a la administración del estado de formularios Web Forms.

Los datos que se suelen insertar en las variables de estado de la aplicación son los datos compartidos por múltiples sesiones y que no cambian a menudo.

Nota Si se almacena un conjunto de datos en el estado de aplicación, se deberá volver a convertir de Object en conjunto de datos. Para obtener detalles, vea Recomendaciones sobre la estrategia de acceso a datos Web.

Las ventajas de utilizar el estado de aplicación son:

• Implementación sencilla. El estado de aplicación es fácil de usar, conocido por los programadores de ASP y coherente con otras clases de .NET Framework.

• Ámbito global. Puesto que el estado de aplicación es accesible para todas las páginas de una aplicación, utilizarlo para almacenar información se traduce en guardar una única copia de la información (a diferencia, por ejemplo, de guardar copias de la información en el estado de sesión o en páginas individuales).

Las desventajas de utilizar el estado de aplicación son:

• Ámbito global. La naturaleza global del estado de aplicación puede también representar un inconveniente. Las variables que se almacenan en el estado de la aplicación son globales sólo para el proceso en el que se está ejecutando la aplicación y cada proceso de aplicación puede tener valores diferentes. Por lo tanto, no puede basarse en el estado de la aplicación para almacenar valores únicos o para actualizar contadores globales en configuraciones Web-garden y de baterías de servidores Web.

• Durabilidad. Como los datos globales almacenados en el estado de la aplicación son volátiles, se perderán si se destruye el proceso de servidor Web que los contiene, en la mayoría de los casos porque el servidor se quede bloqueado, se actualice o se apague.

• Requisitos de recursos. El estado de aplicación necesita memoria del servidor, lo que puede afectar al rendimiento del mismo, así como a la escalabilidad de la aplicación.

Mediante un cuidadoso diseño y una buena implementación del estado de la aplicación puede mejorar el rendimiento de la aplicación Web. Por ejemplo, si se utiliza el estado de aplicación para guardar conjuntos de datos de uso común y relativamente estáticos, se puede aumentar el rendimiento del sitio mediante la reducción del número global de solicitudes a la base de datos. Sin embargo, existe una contrapartida relativa al rendimiento. Las variables de estado de aplicación que contienen grandes bloques de información reducen el rendimiento del servidor Web a medida que aumenta la carga del mismo. La memoria que ocupa una variable almacenada en el estado de la aplicación no se libera hasta que el valor es eliminado o reemplazado. Por tanto, es mejor utilizar variables de estado de aplicación sólo con conjuntos de datos pequeños y cuya modificación sea poco frecuente. Para obtener más información sobre la optimización de aplicaciones Web ASP.NET, vea Optimización de ASP.NET.

Estado de sesión

ASP.NET proporciona el estado de sesión, disponible mediante la clase HttpSessionState, como método para almacenar información específica de la sesión de forma que sea visible sólo dentro de ésta. Para obtener más información, vea Introducción a la administración del estado de formularios Web Forms y Estado de sesión.

11

Se pueden almacenar los valores y objetos específicos de la sesión en el estado de sesión, que el servidor administra, y que está disponible para el explorador o el dispositivo cliente. Lo ideal es almacenar en las variables de estado de la sesión datos de duración corta, datos confidenciales para una sesión individual específica.

Nota Si se almacena un conjunto de datos en el estado de aplicación, se deberá volver a convertir de Object en conjunto de datos. Vea Recomendaciones sobre la estrategia de acceso a datos Web.

Las ventajas de utilizar el estado de sesión son:

• Implementación sencilla. El estado de sesión es fácil de usar, conocido por los programadores de ASP y coherente con otras clases de .NET Framework.

• Eventos específicos de sesión. Su aplicación puede producir y utilizar los eventos de administración de sesión.

• Durabilidad. Los datos guardados en variables de estado de sesión pueden sobrevivir al reinicio de los Servicios de Internet Information Server (IIS) y al reinicio de los procesos de trabajo sin perder datos de sesión, ya que éstos se almacenan en otro espacio de proceso.

• Escalabilidad de plataforma. El estado de sesión se puede utilizar en configuraciones multisistema y multiproceso, optimizando así las diversas situaciones de escalabilidad.

• El estado de sesión funciona con los exploradores que no admiten las cookies HTTP, aunque se suele utilizar en combinación con éstas para proporcionar servicios de identificación de usuario a las aplicaciones Web. Para obtener más información sobre el uso del estado de sesión sin cookies, vea Secciones de configuración de ASP.NET.

Para obtener más información, vea Estado de la sesión.

La desventaja de utilizar el estado de sesión es:

• Rendimiento. Las variables de estado de la sesión permanecen en memoria hasta que se eliminan o reemplazan y pueden empeorar el rendimiento del servidor. Las variables de estado de la sesión que contienen grandes bloques de información como conjuntos de datos, pueden afectar negativamente al rendimiento del servidor Web a medida que aumenta la carga.

Compatibilidad con bases de datos

En algunos casos, puede preferir el uso de la compatibilidad con bases de datos para conservar el estado en el sitio Web. Generalmente, la compatibilidad con bases de datos se utiliza en combinación con las cookies o el estado de sesión. Por ejemplo, es muy frecuente que un sitio Web de comercio electrónico conserve la información de estado mediante una base de datos relacional por las siguientes razones:

• Seguridad • Personalización • Coherencia • Extracción de datos

Las características típicas de un sitio Web con base de datos combinado con cookies:

• Seguridad. El usuario escribe un nombre de cuenta y una contraseña en una página de inicio de sesión del sitio. La infraestructura del sitio hace una consulta en la base de datos con los valores de inicio de sesión para determinar si el usuario dispone de los permisos necesarios para utilizar el sitio. Si la base de datos valida la información del usuario, el sitio Web distribuirá una cookie válida que

12

contenga un identificador único para ese usuario en el equipo cliente. El sitio concede el acceso al usuario.

• Personalización. Una vez tratada la información de seguridad, el sitio es capaz de distinguir a cada usuario leyendo la cookie en el equipo cliente. Normalmente, los sitios tienen información en la base de datos que describe las preferencias de cada usuario (identificado por un identificador único). Esta relación se conoce como personalización. El sitio puede investigar las preferencias del usuario utilizando el identificador único que contiene la cookie y, a continuación, colocar el contenido y la información a disposición del usuario según sus deseos específicos e ir reaccionando a las preferencias del usuario.

• Coherencia. Si ha creado un sitio Web de comercio electrónico, es posible que desee mantener los registros transaccionales de las compras de productos y servicios realizadas en el sitio. Puede guardar esta información en la base de datos de un modo confiable y hacer referencia a ella con el id. exclusivo del usuario. Puede utilizarla para determinar si una transacción de compra se ha completado y, en el caso de que ésta haya fallado, para determinar el curso de las acciones a seguir. También se puede utilizar para informar al usuario sobre el estado de un pedido situado en el sitio.

• Extracción de datos. La información sobre el uso del sitio, los visitantes o las transacciones de un producto se pueden almacenar de forma segura en la base de datos. Por ejemplo, el departamento de desarrollo de la empresa puede utilizar los datos recogidos del sitio para determinar la línea de productos o la política de distribución para el próximo año. El departamento de marketing puede examinar información demográfica sobre los usuarios del sitio. Los departamentos de ingeniería y soporte pueden analizar las transacciones y observar las áreas donde se podría mejorar el proceso de compra. La mayoría de las bases de datos relacionales a nivel empresarial, como, por ejemplo, Microsoft SQL Server, contienen un amplio conjunto de herramientas para la mayor parte de proyectos de extracción de datos.

Si se diseña el sitio Web para que consulte repetidamente a la base de datos mediante el identificador exclusivo durante cada una de las fases generales de la situación descrita, el sitio mantiene el estado. De esta manera, el usuario percibe que el sitio le recuerda y que reacciona de manera personalizada.

Las ventajas de utilizar una base de datos para conservar el estado son:

• Seguridad. El acceso a bases de datos suele ser muy seguro, ya que exige una rigurosa autenticación y autorización.

• Capacidad. Se puede almacenar en la base de datos tanta información como se desee. • Persistencia. La información de la base de datos se puede almacenar durante el tiempo deseado, y no

está sujeta a la disponibilidad del servidor Web. • Solidez e integridad de datos. Las bases de datos suelen incluir diversas funciones para el

mantenimiento de la corrección de los datos, entre ellas desencadenadores e integridad referencial, transacciones, etc. Si se guarda la información de transacciones en una base de datos (en lugar de en el estado de sesión), es más rápido recuperarse de los errores.

• Accesibilidad. Los datos almacenados en la base de datos son accesibles para una amplia variedad de herramientas de proceso de información.

• Amplia compatibilidad. Existe un gran número de herramientas de bases de datos disponibles así como configuraciones personalizadas.

Las desventajas de utilizar una base de datos para conservar el estado son:

• Complejidad. La utilización de una base de datos para la administración del estado implica configuraciones hardware y software más complejas.

• Rendimiento. Una mala construcción del modelo de datos relacionales puede derivar en problemas de ajuste. También, el uso de demasiadas consultas a la base de datos puede afectar negativamente al rendimiento del servidor.

Resumen de los métodos de administración de estado en el servidor

13

En la tabla siguiente se resumen las opciones de administración de estado del servidor, y cuándo se debe considerar su uso.

Método Utilícelo cuando

Estado de aplicación Se almacena información global que raramente cambia, y que utilizan muchos usuarios, y la seguridad no es una cuestión importante. No utilice el estado de aplicación para almacenar grandes cantidades de información.

Estado de sesión Almacene información de corta duración que es específica de una sesión individual y la seguridad no sea un problema. No utilice el estado de sesión para almacenar grandes cantidades de información. Tenga en cuenta que un objeto de estado de sesión se creará y conservará durante el ciclo de vida de cada sesión de la aplicación. En aplicaciones que hospeden a muchos usuarios, esto puede ocupar un número significativo de recursos de servidor y afectar a la escalabilidad.

Compatibilidad con bases de datos

Almacene gran cantidad de información, administre transacciones o la información deba conservarse aunque se vuelva a iniciar la aplicación o la sesión. Suele utilizarse para la extracción de datos, y la seguridad es una cuestión importante a tener en cuenta.

14

Introducción a la administración del

estado de formularios Web Forms

Las páginas Web se vuelven a crear cada vez que la página se envía al servidor. En la programación Web tradicional, esto se traduce en que toda la información asociada a la página y los controles de la misma se pierden con cada recorrido de ida y vuelta. Por ejemplo, si un usuario escribe información en un cuadro de texto, dicha información se perderá en el recorrido de ida y vuelta desde el explorador o dispositivo cliente al servidor. Para obtener más información, vea Procesamiento de páginas de formularios Web Forms.

Para superar esta limitación inherente a la programación Web tradicional, el marco de trabajo de las páginas ASP.NET incluye diversas opciones que ayudan a conservar los cambios; es decir, opciones de administración de estado. El marco de trabajo de la página 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 de un recorrido de ida y vuelta a otro. Sin embargo, es posible que también haya valores específicos de la aplicación que se desee conservar. Para ello, se puede utilizar una de las opciones de administración de estado.

Alguna de estas opciones mantienen la información en el cliente, por ejemplo, directamente en la página o en una cookie, y otras almacenan la información en el servidor entre acciones de ida y vuelta. Cada opción tiene sus ventajas y desventajas.

Opciones de administración de estado basada en cliente

Las siguientes secciones describen opciones para administrar el estado que almacenan la información en la página o en el equipo cliente. En estas opciones, la información no se conserva en el servidor entre acciones de ida y vuelta.

Estado de la vista

La propiedad Control.ViewState proporciona un objeto de diccionario para conservar valores entre las distintas peticiones de una misma página. Este es el método 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.

Cuando se procesa la página, el estado actual de la página y de los controles se guarda troceado en una cadena, que se guarda en la página en forma de campo oculto. Cuando se vuelve a enviar la página al servidor, la página analiza la cadena de estado de vista y restablece en ella la información de propiedades.

En un estado de vista se puede también almacenar valores. Para obtener detalles, vea Guardar valores de páginas de formularios Web Forms mediante el estado de vista. Para obtener recomendaciones de uso del estado de vista, vea Recomendaciones de administración de estado.

Campos de formulario ocultos

ASP.NET permite utilizar en un formulario campos ocultos HTML estándar. Un campo oculto no está visible 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 en la colección Form de HTTP junto con los valores de otros controles. Un campo oculto actúa como un repositorio de cualquier información específica que desee almacenar directamente en la página.

15

Nota de seguridad Es fácil que un usuario malicioso vea y modifique el contenido de un campo oculto. No almacene ninguna información que sea confidencial o en la que se base la aplicación para funcionar correctamente en un campo oculto.

Un campo oculto almacena una única variable en su propiedad value, y se debe agregar a la página de forma explícita. Después se inserta el valor en el campo oculto. ASP.NET ofrece el control HtmlInputHidden, que ofrece funciones para el manejo de campos ocultos. Para obtener más información, vea Controles de servidor ASP.NET por función.

Para que los valores de los campos ocultos estén disponibles durante el procesamiento de la página, debe enviar la página utilizando el método POST de HTTP. Es decir, no puede beneficiarse de los campos ocultos si la página se procesa como respuesta a un vínculo o a un método GET de HTTP. Para obtener recomendaciones de uso, vea Recomendaciones de administración de estado.

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 memoria en la sesión del explorador cliente. Contiene información específica de la página que envía el servidor al cliente junto con el resultado de la página. Las cookies pueden ser temporales (con fechas y horas de caducidad específicas) o permanentes.

Las cookies se pueden utilizar para almacenar información acerca de un cliente, sesión o aplicación específicos. Las cookies se guardan en el dispositivo cliente y, cuando el explorador solicita una página, envía la información de la cookie junto con la información de 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.

Nota de seguridad El explorador puede devolver los datos sólo al servidor que creó la cookie. Sin embargo, algunos usuarios con malas intenciones cuentan con medios para "robar" cookies y leer su contenido. Se recomienda no almacenar información confidencial, como el nombre de usuario o la contraseña, en una cookie. En su lugar, almacene un símbolo (token) que pueda utilizar para buscar la información reservada en el servidor.

Para obtener más información sobre el uso de cookies, vea HttpResponse.Cookies (Propiedad) y Recomendaciones de administración de estado.

Cadenas de consulta

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

http://www.contoso.com/listwidgets.aspx?category=basic&price=100

En la ruta URL indicada, la cadena de consulta empieza con un signo de interrogación (?) e incluye dos parejas de atributo-valor, una de ellas denominada "category", y la otra denominada "price".

Las cadenas de consulta proporcionan una manera sencilla pero limitada de mantener cierta información de estado. Por ejemplo, es una manera sencilla de pasar información de una página a otra, por ejemplo, pasar un código de producto de una página a otra donde se procesará. Sin embargo, en la mayoría de los exploradores y dispositivos de cliente la longitud de la dirección URL tiene una limitación de 255 caracteres.

Nota de seguridad La información pasada en una cadena de consulta puede ser manipulada por un usuario con malas intenciones. No utilice cadenas de consulta para

16

transmitir información importante o confidencial. Para obtener más información, vea Ataques mediante secuencias de comandos.

Para que los valores de las cadenas de consulta estén disponibles durante el procesamiento de la página, debe enviar la página utilizando el método get de HTTP. Es decir, no puede beneficiarse de las cadenas de consulta si la página se procesa como respuesta a un método post de HTTP. Para obtener recomendaciones de uso, vea Recomendaciones de administración de estado.

Opciones de administración de estado basada en servidor

ASP.NET le ofrece distintas maneras de conservar la información de estado en el servidor, como se describe en las secciones siguientes.

Estado de aplicación

ASP.NET permite guardar valores utilizando el estado de la aplicación (una instancia de la clase HttpApplicationState) para cada aplicación Web activa. 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. Para obtener más información, vea Estado de la aplicación.

Estado de aplicación es una estructura de diccionario de tipo clave-valor que se crea durante cada solución a una URL específica. Puede agregar información específica de la aplicación a esta estructura para almacenarla entre las peticiones de página.

Después de agregar la información específica de la aplicación a estado de aplicación, el servidor se encarga de administrarla. Para obtener recomendaciones de uso, vea Recomendaciones de administración de estado.

Estado de sesión

ASP.NET permite guardar valores utilizando el estado de sesión, que es una instancia de la clase HttpSessionState para cada sesión de aplicación Web activa. (Para obtener una introducción, vea Estado de la sesión).

Estado de sesión es similar a estado de aplicación, con la diferencia de que el ámbito es la actual sesión del explorador. Si hay distintos usuarios utilizando la aplicación, cada uno de ellos tendrá un estado de sesión distinto. Asimismo, si el mismo usuario deja la aplicación y vuelve más tarde, el usuario tendrá también un estado de sesión distinto.

Estado de sesión tiene la estructura de un diccionario de tipo clave-valor para almacenar información específica de cada sesión que debe conservarse entre recorridos de ida y vuelta del servidor y entre solicitudes de páginas. Para obtener más información, vea Estado de la sesión.

Estado de sesión permite:

• Identificar unívocamente las peticiones del explorador o del dispositivo de cliente y asignarlas a una instancia de sesión individual en el servidor.

• Almacenar en el servidor datos específicos de la sesión para utilizarlos a través de múltiples peticiones del explorador o dispositivo dentro de la misma sesión.

• Producir eventos de administración de sesión adecuados. Adicionalmente, puede escribir código de aplicación para aprovechar estos eventos.

17

Después de agregar la información específica de la aplicación a estado de sesión, el servidor se encarga de administrar dicho objeto. En función de las opciones especificadas, la información de sesión se puede almacenar en cookies, en un servidor que no forme parte del proceso, o en un SQL Server. Para obtener recomendaciones de uso, vea Recomendaciones de administración de estado.

Compatibilidad con bases de datos

Es una práctica común conservar el estado utilizando tecnología de bases de datos para almacenar una gran cantidad de información específica del usuario. El almacenamiento en bases de datos es especialmente útil para conservar el estado a largo plazo, o para conservarlo aún en el caso de que se deba reiniciar el servidor.

El enfoque mediante bases de datos se suele utilizar en combinación con las cookies. Por ejemplo, cuando un usuario tiene acceso por primera vez a la aplicación, puede hacer que el usuario inicie una sesión. Después, puede buscar al usuario en su base de datos y pasarle una cookie. La cookie puede contener únicamente el identificador del usuario en la base de datos (por ejemplo, un número de cliente). A continuación se puede utilizar la cookie en las solicitudes subsiguientes para buscar la información del usuario en la base de datos, según sea necesario.

Nota de seguridad Puesto que las cookies pueden ser manipuladas por personas con malas intenciones, debe tener cuidado al utilizarlas para almacenar información en la que se basa la aplicación. Por ejemplo, nunca guarde información confidencial en una cookie. Si utiliza cookies para almacenar símbolos (como un id. de usuario), considere la posibilidad de cifrar el valor de la cookie o agregar lógica para estar seguro de que nadie manipula el valor de la cookie.

La compatibilidad con bases de datos le permite:

• Identificar de forma exclusiva las solicitudes del explorador o el dispositivo cliente y asignarlas a un identificador único.

• Mantenga el estado relacionando la información almacenada con un id. exclusivo. Puede utilizar el id. exclusivo para consultar una base de datos con el fin de obtener información relacionada con ese id. A continuación, puede modificar la información y guardarla de nuevo en la base de datos para utilizarla en varias solicitudes de las mismas páginas del sitio u otras diferentes.

• Producir eventos adecuados. Una condición en la base de datos puede determinar la acción del sitio. Por ejemplo, si el usuario de un sitio Commerce intenta comprar algo que no está en stock, una consulta a la base de datos puede transmitirle al sitio Web que le pida al usuario que haga otra selección.

Para obtener más información acerca del uso de una base de datos para mantener el estado, vea Recomendaciones de administración de estado.

18

Contexto de página y aplicación en

aplicaciones de formularios Web Forms

Cuando se ejecuta una aplicación Web, ASP.NET mantiene información sobre la aplicación actual, cada sesión de usuario, la solicitud HTTP actual, la página de formularios Web Forms solicitada, etc. El marco de trabajo de páginas ASP.NET contiene una serie de clases para encapsular esta información de contexto.

ASP.NET hace que instancias de estas clases estén disponibles como objetos intrínsecos a los que se puede tener acceso desde el código. La tabla siguiente enumera estos objetos intrínsecos y las clases de las que son instancias.

Nota Aunque las clases que definen estos objetos son nuevas en ASP.NET, los objetos se utilizan del mismo modo que en versiones anteriores de ASP.

Nombre de

objeto

Descripción Clase ASP.NET

Response Proporciona acceso a la secuencia de salida de la página actual. Puede utilizar esta clase para insertar texto en la página, escribir cookies y mucho más. Para obtener información detallada, vea Page.Response (Propiedad).

HttpResponse

Request Proporciona acceso a la solicitud de página actual, incluidos los encabezados de solicitud, las cookies, el certificado de cliente, la cadena de consulta, etc. Puede utilizar esta clase para leer lo que ha enviado el servidor. Para obtener información detallada, vea Page.Request (Propiedad).

HttpRequest

Context Proporciona acceso a todo el contexto actual (incluido el objeto de la solicitud). Puede utilizar esta clase para compartir información entre páginas.

HttpContext

Server Expone métodos de utilidad que puede utilizar para transferir el control entre páginas, obtener información sobre el error más reciente, codificar y descodificar texto HTML, y mucho más.

HttpServerUtility

Application Proporciona acceso a métodos y eventos de aplicación para todas las sesiones. También proporciona acceso a una caché de aplicación que puede utilizar para

HttpApplicationState

19

almacenar información. Para obtener información detallada, vea Estado de la aplicación.

Session Proporciona información de la sesión de usuario actual. También proporciona acceso a una caché de sesión que puede utilizar para almacenar información, junto con los medios para controlar la administración de la sesión. Para obtener información detallada, vea Estado de sesión.

HttpSessionState

Trace Proporciona un modo de obtener mensajes de diagnóstico de seguimiento personalizados y del sistema para mostrarlos en el resultado de la página HTTP. Para obtener información detallada, vea Funcionalidad de seguimiento ASP.NET.

TraceContext

Los temas siguientes muestran ejemplos de cómo utilizar los objetos intrínsecos.

Objeto Temas de ejemplo

Application • Código: Leer valores de un estado de aplicación (Visual Basic) • Código: Guardar valores en un estado de aplicación (Visual

Basic)

Request • Código: Leer una cookie (Visual Basic) • Código: Recuperar la información del explorador de un cliente

(Visual Basic) • Código: Escribir una cookie (Visual Basic)

Server • Código: Codificar texto HTML (Visual Basic) • Código: Controlar errores de aplicación (Visual Basic) • Código: Controlar errores de página (Visual Basic) • Código: Redirigir a otra página en la misma aplicación (Visual

Basic)

Session • Código: Almacenar en caché un conjunto de datos en un estado de sesión (Visual Basic)

• Código: Leer valores de un estado de sesión (Visual Basic) • Código: Guardar valores en un estado de sesión (Visual Basic)

20

Redirigir a los usuarios a otra página

Quizá desee redirigir a los usuarios de una página de formulario Web Forms a otra. El motivo puede ser mostrar una página que coincida con la funcionalidad del explorador del usuario o que esté escrita en el idioma que el usuario habla.

Existen dos formas de redirigir páginas:

• Utilizando un método de servidor. En este escenario, el servidor sólo transfiere el contexto a otra página. La ventaja es que puede compartir información de contexto de página entre páginas. El inconveniente es que el explorador del usuario no tiene conocimiento de la transferencia, por lo que no se actualiza su historial. Si el usuario actualiza la página, pueden producirse resultados inesperados.

• Utilizando el explorador. En este escenario, se envía un comando al explorador del usuario que da lugar a que el explorador muestre una página diferente. La ventaja es que se actualiza el historial del explorador. El inconveniente es que este escenario realiza una acción de ida y vuelta adicional que puede afectar al rendimiento.

Para redirigir a los usuarios a otra página utilizando un método de servidor

• Llame al método Server.Transfer y pásele el nombre de la página a la que desea redirigir a los usuarios.

• El ejemplo siguiente muestra cómo redirigir a otra página. • ' Visual Basic

• Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

• Server.Transfer("Webform2.aspx")

• End Sub

•

• // C#

• private void Button1_Click(object sender, System.EventArgs e)

• {

• Server.Transfer("Webform2.aspx"); }

Para obtener información detallada sobre el compartimiento del contexto de página durante una transferencia de servidor, vea Pasar valores entre páginas de formularios Web Forms.

Para redirigir a los usuarios a otra página desde el explorador

1. Establezca la propiedad BufferOutput del objeto Response en true.

21

2. Llame al método Redirect del objeto Response, y pásele la URL de la página a la que se debe redirigir.

A continuación se muestra cómo redirigir en función del contenido de una variable local, UserLanguage, cuyo valor se establece en otra parte.

' Visual Basic Response.BufferOutput = True If UserLanguage = "English" Then Response.Redirect("http://www.microsoft.com/gohere/look.htm") ElseIf UserLanguage = "Deutsch" Then Response.Redirect("http://www.microsoft.com/gohere/look_deu.htm") ElseIf UserLanguage = "Español" Then Response.Redirect("http://www.microsoft.com/gohere/look_esp.htm") End If // C# Response.BufferOutput = true; if (UserLanguage == "English") { Response.Redirect("http://www.microsoft.com/gohere/look.htm"); } else if (UserLanguage == "Deutsch") { Response.Redirect("http://www.microsoft.com/gohere/look_deu.htm"); } else if (UserLanguage == "Español") { Response.Redirect("http://www.microsoft.com/gohere/look_esp.htm"); }