Programación en Redes I
ASP .NET 2.0
Client-Side Event Procedures
Se puede definir como eventos que son administrados en la PC que peticiona el Web Form (el cliente). Al generar un evento, la información no es enviada al servidor. En su lugar, el explorador del cliente interpreta el código y realiza la acción. nunca se tienen acceso a los recursos del servidor. Por ejemplo, no se puede utilizar un client-side script para acceder a una base de datos SQL. Muy útil para eventos que quiera que ocurran inmediatamente, porque no requiere enviar información al servidor Web y esperar una respuesta. Por ejemplo, validar un text box sin acceder a un servidor. podemos usar client-side script para validar rápida y efectivamente antes de enviar información al Web Server.
Para especificar que el evento ocurra del lado del cliente puede utilizar el siguiente código:
<SCRIPT language=“javascript”>
Server-Side Event Procedures
A diferencia del anterior, Server-side event procedures requiere enviar información al Web Server para ser procesada. Existe una ligera perdida de tiempo usando Server-side event procedures, pero son más poderosos que Client-side event procedures. consiste de código compilado en el Servidor, administra eventos desde controles Web y HTML. tienen acceso a recursos de servidor que no disponibles para Client-side event procedures. Se puede utilizar Server-side event procedures especificando el atributo runat=“server” en el script tag.
<SCRIPT language=“vb” runat=“server”>
limitado controles de eventos que son soportados.
Entendiendo el ciclo de vida de una pagina
Al momento de que una pagina ASP.NET es pedida, se generan una serie de eventos siempre en el mismo orden:
1. Page_Init: este evento de pagina inicializa la pagina creando e inicializando los Web Server controls sobre la pagina.
2. Page_Load: este evento de pagina ocurre cada vez que la pagina es peticionada
3. Control events: este evento de pagina incluye los eventos change (por ejemplo, TextBox1_Changed) y los eventos action (por ejemplo: Button1_Click)
4. Page_unload: este evento de pagina ocurre cuando la pagina es cerrada o cuando el control es pasado a otra pagina.
El final del ciclo de vida de la pagina incluye la descarga de la pagina de memoria.
Algunos eventos no ocurren hasta que el Web Form realiza un postback(devolución de datos) al servidor. Por ejemplo, el evento Change es administrado después que el formulario es posteado(enviado). Por lo contrario, los eventos Click pueden causar el envió inmediato al servidor.
El proceso Postback, definicion
Se llama así al proceso que efectúa un formulario para enviar información al servidor. Ocurren con ciertas acciones de los usuarios, solo el evento clic de un botón hace que el formulario realice un postback al servidor. O si se configura la propiedad AutoPostBack de un control a True, el postback es forzado para eventos del control.
ASP.NET Web Application
La creación de aplicaciones Web con ASP.NET incluyen las siguientes partes:
• Web forms o paginas aspx: los Web forms o paginas aspx proveen la UI para la aplicación Web.
• Paginas Code-behind: son paginas asociadas con Web Forms y contienen el código Server-side para el Web form.
• Archivos de configuración: son archivos XML que contienen la configuración por defecto para la aplicación Web y el servidor Web. Cada aplicación Web tiene un archivo de configuración llamado Web.config. Además cada servidor Web un archivo llamado machine.config
• Archivo Global.asax: dicho archivo contiene el código que necesita para responder a los eventos de aplicación que son levantados por ASP.NET
• Vínculos XML Web Service: estos vínculos permiten a la aplicación Web enviar y recibir datos desde un XML Web service.
• oectividad de base de datos: permite a la aplicación Web transferir datos desde y hacia la base de datos
• Caching: permite a las aplicaciones retornar Web forms y datos mas rápidamente luego de la primer petición.
ASP.NET Execution Model
Cuando un cliente peticiona por primera vez una pagina Web, ocurren los siguientes eventos:
1. El cliente desde su explorador emite una petición GET HTTP al servidor
2. El parser de ASP.NET interpreta el código
3. Si el código no está compilado dentro de una librería (DLL), ASP.NET invoca al compilador
4. El runtime carga y ejecuta el código intermedio (MSIL – Microsoft intermediate language)
Cuando el cliente peticiona por segunda vez la misma pagina Web, lo siguiente ocurre:
1. El cliente emite una petición GET HTTP al servidor
2. Runtime carga e inmediatamente ejecuta el código MSIL que ya fu compilado durante la primer petición.
Las aplicaciones Web ASP.NET componentes
• Formularios Web o páginas .ASPX: Proveen de la interfase visual. No tienen código ejecutable.
• Páginas de Código por detrás: Están asociadas con cada formulario y son las que proveen del código ejecutable.
• Archivos de Configuración: Son archivos que permiten configurar la aplicación, por ejemplo el archivo Web.config y el servidor por ejemplo el archivo machine.config.
• Global.asax: Es un archivo que contiene código. Este código responde a eventos que se disparan en la aplicación Web.
Proyecto Web
• Formulario Web ASP.NET (.aspx): Es la interfase visual de la aplicación Web. Puede tener código por detrás., cuyo nombre es Formulario.aspx.vb o Formulario.aspx.cs
• Clases y código por detrás (.cs y .vb): Son las clases que utiliza el proyecto y el código de soporte de los formularios y los servicios.
• Clase Global (.asax): Es un archivo que contiene código de eventos a nivel de aplicación.
• Web.config: Es un archivo XML con información de configuración.
• Archivos ensamblados del proyecto (.dll): Todas las paginas de código por detrás de una aplicación son compilados en un solo DLL que se guarda en el directorio /bin con el nombre de NombreDeProyecto.dll
• VsProj o CsProj: Vs Proj es la extensión de un proyecto si usted escribió la aplicación en Visual.NET. CsProj es la extensión si utilizo c#
Que es un Web Form?
Son páginas Web programables que sirven como interfaz de usuario de las aplicaciones Web. Presenta la información al usuario en cachocirualquier explorador o dispositivo cliente e implementa lógica de aplicación mediante el código de la parte servidor. compatible con HTTP, incluidos HTML, XML, WML y ECMAScript (JScript, JavaScript).
características:
Se basan en la tecnología Microsoft ASP.NET, Para obtener información detallada sobre ASP.NET, vea Información básica sobre tecnología ASP.NET.
Compatible con cualquier explorador o dispositivo móvil. Las páginas de formularios Web Forms presentan automáticamente el código HTML adecuado al explorador para funciones tales como estilos, diseño, etc. Como alternativa, se pueden diseñar las páginas de formularios Web Forms para ejecutarse en un explorador determinado, como Microsoft Internet Explorer 5 y aprovechar así todas las funciones de un cliente de explorador de nivel superior.
Admiten cualquier lenguaje compatible con Common Language Runtime de .NET, incluidos Microsoft Visual Basic, Microsoft Visual C# y Microsoft JScript.NET.
Se crean en el entorno Microsoft .NET Framework. Esto proporciona todos los beneficios del marco de trabajo, incluidos un entorno administrado, seguridad de tipos y herencia.
Respaldadas en Visual Studio por eficaces herramientas de desarrollo rápido de aplicaciones (RAD, Rapid Application Development) destinadas al diseño y la programación de los formularios.
Componentes de los formularios Web Forms
En las páginas de formularios Web Forms, la programación de la interfaz de usuario se divide en dos partes independientes: el componente visual y el lógico. Si ha trabajado con herramientas como Visual Basic y Visual C++ anteriormente, reconocerá esta división entre la parte visible de un formulario y el código que se oculta detrás y que interactúa con él.
El elemento visual se conoce como la página de formularios Web Forms, y se compone de un archivo que contiene código HTML estático, o controles de servidor ASP.NET o ambos de forma simultánea.
La página de formularios Web Forms funciona como un contenedor del texto y los controles estáticos que se desea mostrar. Si se usa el Diseñador de Web Forms de Visual Studio junto con controles de servidor ASP.NET, se pueden diseñar los formularios igual que se haría en cualquier aplicación de Visual Studio. Para obtener más información, vea Controles que se pueden usar en páginas de formularios Web Forms.
Ventajas que aportan las páginas de formularios Web Forms
• Implementar una interfaz de usuario Web enriquecida. Una interfaz de usuario con un diseño complejo, una gran cantidad de contenido dinámico y llena de objetos interactivos.
• Separación entre cliente y servidor. En las aplicaciones Web, el cliente (explorador) y el servidor son programas distintos que a menudo se ejecutan en equipos distintos e, incluso, en sistemas operativos diferentes.
• Ejecución independiente. Cuando un servidor Web recibe una petición de una página, la busca, la procesa y la envía al explorador y, a continuación, desecha toda la información sobre dicha página. Si el usuario solicita la página de nuevo, el servidor repite la secuencia completa, volviendo a procesar la página desde el principio.
• Posibilidades desconocidas del cliente. En muchos casos, las aplicaciones Web resultan accesibles a usuarios que poseen exploradores de distintos fabricantes y que, por tanto, ofrecen distinta funcionalidad, lo que hace muy difícil crear una aplicación que se ejecute con la misma calidad en todos ellos.
• Complicaciones con el acceso a los datos. La lectura de los datos de un origen de datos y la escritura en el mismo puede resultar complicada con las aplicaciones Web tradicionales y hacer un gran uso de los recursos.
• Complicaciones con la escalabilidad. En muchos casos las aplicaciones Web diseñadas con los métodos existentes no pueden cumplir los objetivos de escalabilidad debido a la falta de compatibilidad entre sus distintos componentes.
• Atajar estos retos de las aplicaciones Web puede requerir un tiempo y esfuerzo importantes. Las páginas de formularios Web Forms y el marco de trabajo de páginas ASP.NET tratan de solucionar estos temas de los modos siguientes:
Flexibles gracias a la posibilidad de incorporar a ellas controles creados por los usuarios y de otros fabricantes.
El web.config
sirve para configurar la aplicación ASP.NET o parte de ella, Puede existir un web.config en cada carpeta de la aplicación y configurará opciones para todas las subcarpetas de la misma. En el web.config de definen los roles de acceso, membresías, conexión a base de datos y las variables propias de la aplicación entre otras configuraciones.
Para crear nuevos Web forms en aplicaciones ASP.NET nuevas, es muy sencillo:
1. En la pagina de inicio de Visual Studio .NET, clic en nuevo proyecto
2. En la caja de diálogos del proyecto nuevo, ingrese el nombre del nuevo proyecto y luego clic en OK
3. Visual Studio crea una nueva aplicación Web y un Web Form llamado WebForm1.aspx
Creación de nuevos Web Forms a un proyecto existe:
1. En el Explorador de Soluciones, clic derecho en el nombre del proyecto
2. Luego clic en Agregar Web Form, ingresar el nombre del nuevo Web form y clic en OK
Actualizar paginas HTML existentes:
• En el explorador de soluciones, clic derecho sobre el proyecto, posicionarse en Agregar, y luego en Agregar Elemento existente
• En la caja de diálogos de Nuevo Elemento Existente, posicionarse en donde se encuentra el archivo HTML, y clic en abrir.
• Renombrar el archivo nombre.htm a nombre.aspx y clic en SI, cuando aparezca la advertencia de cambio de extensión.
• Cuando se le pregunta por la creación de un archivo de clases, se debe aprobar.
Modelo de código de pagina web
ASP.NET provee dos modelos para administrar los elementos visuales y el código –
• En el modelo single-file, el HTML y el código de programación se almacena en el mismo .aspx.
• En el modelo code-behind, el HTML esta en un archivo .aspx y el código de programación en otro archivo .aspx.
El modelo code-behind
El archivo code-behind es mas simple. Este incluye solo el código escrito por usted mismo. Usted puede incluir controles de usuarios sin tener que crear variables instanciadas explícitamente para el code-behind class. La pagina code-behind no puede ser sincronizado con los controles declarado en el
Mejor separación de código y contenido
El nuevo modelo de code-behind hace mas fácil la separación del código y del HTML. En el modelo anterior de code-behind, no era practico agregar controles en el HTML sin tener que acceder al code-behind para agregar una variable instanciada al mismo tiempo. En el nuevo modelo usted puede crear paginas en capas sin necesitar tener que acceder a la pagina de code-behind
Que es el view state
Los controles de servidor de ASP.NET heredan de Control una propiedad denominada ViewState que les permite participar fácilmente en el mantenimiento del estado. El tipo de ViewState es System.Web.UI.StateBag, que es un diccionario en el que se almacenan pares de nombre y valor. Si en lugar de un campo privado un control utiliza ViewState para datos de propiedad, la propiedad se conservará automáticamente entre los trayectos de ida y vuelta hacia el cliente.
Solución de Problemas de rendimiento en View State
Enviar gran cantidad de datos a través de Internet puede generar grandes problemas en los tiempos y en el ancho de banda.
Deshabilitar propiedad EnableViewState de cada control.
Deshabilitar el View State para la pagina entera
Guardar el View State en el servidor en lugar de ocultarlo en campo de formularios.
Que es el control State
En un alto nivel de abstracción, control state y view state son similares. Este reemplaza el private view del view state.
El private use del view state ocurre cuando un control almacena el contenido de propiedades no publicas en el view state. La aplicación no puede acceder a dichas propiedades por el nivel de protección y no puede restaurar los valores almacenados.
Session State
Un session state es definido como un periodo de tiempo en el cual un usuario interactúa con la aplicación Web puede definir almacenes de datos personalizados para el session state. Ofrece dos opciones: modificación de pequeños mecanismos del ASP.NET session state y el reemplazo del anterior modulo de session state HTTP por uno nuevo.
Usted puede personalizar y adaptar cuatro aspectos en el modulo del session state: data store, session state ítem, data dictionary, y session ID. Por este propósito, ASP.NET 2.0, introduce nuevos atributos y elementos en la sesión <sessionstate> del archivo web.config.
Cache
Es un contenedor, el cual esta unido a otros dos contenedores clásicos de ASP: application y session. Cache es una tabla hash usada para almacenar los datos accedidos frecuentemente.
La clase CacheDependency encapsula mecanismo de dependencia. La mayor diferencia entre la dependencia de la cache entre la versión ASP.NET 1.x y ASP.NET 2.0 es el soporte para dependencia de cache personalizable que posee ASP.NET 2.0. Para el manejo de dependencias personalizables.
Controles de usuarios
Los controles proveen una gran cantidad de funcionalidades, pero estos no cubren todas las situaciones.
• Web User Controls. Usted puede convertir una pagina Web Form en un Web user control con pocas modificaciones.
• User controls son identificados por la extensión de archivo .ascx.
• Custom controls: Incluyen todas las características de los controles de servidores ASP.NET, incluyendo un completo soporte para las nuevas características de Visual Studio como las propiedades de ventanas, barra de herramientas, etc.
Cuando cree páginas de formularios Web Forms, puede utilizar estos tipos de controles:
• Controles de servidor HTML. Los controles de servidor HTML exponen un modelo de objeto que se relacionan muy estrechamente con los elementos HTML que procesan.
• Controles de servidor Web.- Los controles de servidor Web incluyen no sólo controles de tipo formulario como botones y cuadros de texto, sino también controles con fines especiales como un calendario.
• Controles de servidor HTML Los controles de servidor HTML son elementos HTML que contienen atributos que los hacen visibles (y programables) en un servidor. De forma predeterminada, el servidor no tiene acceso a los elementos HTML de una página de formularios Web Forms: La capacidad de controlar eventos en una secuencia de comandos de cliente, Mantenimiento automático del estado del control. Interacción con controles de validación que permiten comprobar con gran facilidad si el usuario ha escrito la información adecuada en un control. Enlace de datos a una o varias de las propiedades del control.
• Los controles de servidor Web. Se definen como controles abstractos, en los que el HTML real procesado por el control puede ser muy diferente al modelo con respecto al que se han programado. Los controles de servidor Web incluyen controles de formulario tradicionales como botones y cuadros de texto, además de controles complejos, como, por ejemplo, las tablas. También incluyen controles que proporcionan funcionalidad de formulario de uso frecuente, como la presentación datos en cuadrícula, la elección de fechas, etc.Un modelo de objetos enriquecido que proporciona capacidades de programación de tipo seguro.
Custom Control
Los controles Web personalizados son componentes compilados que se ejecutan en el servidor, y que encapsulan la interfaz de usuario y el resto de la funcionalidad relacionada en paquetes reutilizables. Hay varias formas de crear controles Web personalizados:
• Se puede compilar un control que combine la funcionalidad de dos o más controles existentes.
• Si un control de servidor existente casi reúne los requisitos pero le faltan algunas funciones, se puede personalizar creando un derivado suyo y sobrescribiendo sus propiedades, métodos y eventos.
• Si ninguno de los controles de servidor Web existente (ni sus combinaciones) cumplen los requisitos necesarios, se puede crear un control personalizado derivado de una de las clases de controles básicas.
Callbacks en Clientes.
XML-HTTP callbacks, o client callbacks, son mas eficientes que postback por dos razones. Una, la pagina no es renderizada (la pagina procesa un stop antes del evento PreRender). Segundo, los formularios no son aprobados, lo cual significa que ni la información ingresada en el formulario ni el estado de la vista actual son transmitidas al servidor como un full-blown postback. Mientras que el Internet Explorer soporta callbacks sincrónicos y asincrónicos, ASP.NET 2.0’s client callbacks manager siempre trabaja con callbacks asincrónicos
Como trabajan los Callbacks en Clientes.
El primer paso en la mejora del rendimiento de un client callback es la llamada al método GetCallBackEventReference para obtener el nombre de la función del lado del cliente que puede ser llamada para inicializar un callback. Entonces usted llama a la función del lado del cliente (utilizando un script de lado cliente), el cual se conecta con ASP.NET’s callback manager, el cual esta implementado en el lado del cliente, para conectarse con XML-HTTP callback al servidor.
ASP.NET notifica a la pagina que un callback a llegado por medio del método ICallbackEventHandler.RaiseCallbackEvent. RaiseCallbackEvent procesa el callback y lo retorna.
