Procesamiento de páginas de formularios Web Forms

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
1
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:
2
•
•
•
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
3
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
Inicialización del
marco de trabajo de
página ASP.NET
Inicialización del
código de usuario
Significado
Usos típicos
Se produce el evento Page_Init de la Durante este evento, el marco de trabajo de
página y se restaura el estado de vista página ASP.NET restaura las propiedades de
de la página y los controles.
los controles y de los datos devueltos.
Se produce el evento Page_Load de la Leer y restaurar valores almacenados
página.
previamente:
•
•
•
•
Validación
Control de eventos
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.
El método Validate de cualquier
(En esta fase no existe ningún enlace de
control de servidor Web de validación usuario. Puede probar el resultado de la
permite ejecutar la validación
validación en un controlador de evento).
especificada del control.
En esta fase, si la página fue llamada Realizar el procesamiento específico de la
en respuesta a un evento del
aplicación:
formulario, se llama al controlador de
evento correspondiente.
• 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
4
Fase
Significado
Usos típicos
procesan antes de enviar el
evento.
•
•
•
•
Limpieza
Se llama al evento Page_Unload
porque la página ha terminado de
procesarse y está lista para ser
eliminada.
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.
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
5
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.
6
•
•
•
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.
7
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:
8
•
•
•
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
Estado de vista
Campos ocultos
Cookies
Cadena de consulta
Utilícelo cuando
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.
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.
Necesite almacenar cantidades pequeñas de información en el cliente y la seguridad
no sea un problema.
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
9
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.
10
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
11
•
•
•
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
12
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
Estado de aplicación
Estado de sesión
Compatibilidad con
bases de datos
Utilícelo cuando
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.
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.
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.
13
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.
14
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
15
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.
16
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.
17
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
Response
Request
Context
Server
Application
Descripción
Clase ASP.NET
Proporciona acceso a la secuencia de
HttpResponse
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).
Proporciona acceso a la solicitud de
HttpRequest
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).
Proporciona acceso a todo el contexto HttpContext
actual (incluido el objeto de la solicitud).
Puede utilizar esta clase para compartir
información entre páginas.
Expone métodos de utilidad que puede HttpServerUtility
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.
Proporciona acceso a métodos y eventos HttpApplicationState
de aplicación para todas las sesiones.
También proporciona acceso a una caché
de aplicación que puede utilizar para
18
Session
Trace
almacenar información. Para obtener
información detallada, vea Estado de la
aplicación.
Proporciona información de la sesión de HttpSessionState
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.
Proporciona un modo de obtener
TraceContext
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.
Los temas siguientes muestran ejemplos de cómo utilizar los objetos intrínsecos.
Objeto
Application
Request
•
•
•
•
•
Temas de ejemplo
Código: Leer valores de un estado de aplicación (Visual Basic)
Código: Guardar valores en un estado de aplicación (Visual
Basic)
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)
•
•
19
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.
20
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");
}
21