ASP.NET 2.0
Client-Side Event Procedures._ Son eventos que son administrados sobre la computadora que peticiona el Web Form (el cliente), el explorador del cliente interpreta el código y también realiza la acción, nunca tienen acceso a los recursos del servidor.Server-Side Event Procedures._ Requiere de información para ser enviada al Web Server para ser procesada. Consiste de código compilado que reside sobre el Web Server, puede ser usado para administrar eventos que son generados desde controles Web y HTML, tienen acceso a recursos de servidor
El ciclo de vida de una pagina
Cuando una página ASP.NET es pedida, hay una serie de eventos que ocurren en el mismo orden, El ciclo de vida de la página ocurren en el siguiente 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 página ocurre cuando la página es cerrada o cuando el control es pasado a otra página.
El final del ciclo de vida de la página incluye la descarga de la página de memoria.
El proceso Postback._ En ASP los formularios son diseñados para enviar información al servidor para ser procesada, este proceso es llamado postback. Ocurren con ciertas acciones de los usuarios. Por defecto, solo el evento clic de un botón causa que el formulario realice un postback al servidor
Web Application._ Contiene diferentes partes y componentes, involucra el uso y trabajo con estas partes y componentes. Las partes que una aplicación Web con ASP.NET son las siguientes:
• 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.
• Conectividad 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 más rápidamente luego de la primer petición.
Execution Model._ Cuando un cliente peticiona por primera vez una página 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 que no está actualmente 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 página 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.
Componente de las aplicaciones web
Formularios Web o páginas .ASPX._ Proveen de la interface 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 para 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.confi._ Es un archivo XML con información de configuración.
Archivos ensamblados del proyecto (.dll)._ Todas las páginas 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._ Pueden usarse para crear páginas Web programables que sirvan como interfaz de usuario de las aplicaciones Web, este tipo de páginas presenta la información al usuario en cualquier explorador o dispositivo cliente e implementa lógica de aplicación mediante el código de la parte servidor, la salida de las páginas de formularios Web Forms puede contener casi cualquier lenguaje compatible con HTTP, incluidos HTML, XML, WML y ECMAScript (JScript, JavaScript).
Las páginas de formularios Web Forms reúnen las siguientes características:
Se basan en la tecnología Microsoft ASP.NET, en la que el código que se ejecuta en el servidor genera de forma dinámica salida de páginas Web en un explorador o dispositivo cliente.
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
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.
Extensibles mediante controles que proporcionan posibilidades RAD al desarrollo Web, lo que permite crear con rapidez interfaces de usuario enriquecidas.
Flexibles gracias a la posibilidad de incorporar a ellas controles creados por los usuarios y de otros fabricantes.
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. 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. La lógica de las páginas de formularios Web Forms se compone del código creado para interactuar con el formulario. La lógica de programación reside en un archivo independiente del archivo de la interfaz de usuario. Este archivo se conoce como el archivo de "código subyacente" y adopta la extensión ".aspx.vb" o ".aspx.cs". La lógica escrita en el archivo de código subyacente puede estar en Visual Basic o en Visual C#.
Los archivos de código subyacente de todas las páginas de formularios Web Forms de un proyecto se compilan en el archivo de biblioteca de vínculos dinámicos (.dll) del proyecto. El archivo de página .aspx también se compila, pero de un modo distinto. La primera vez que un usuario examina la página .aspx con el explorador, ASP.NET genera automáticamente un archivo de clase .NET que representa a la página y que la compila en un segundo archivo .dll. La clase generada para la página .aspx hereda de la clase del código subyacente que se compiló en el archivo .dll del proyecto . Cuando un usuario solicita la dirección URL de la página Web, los archivos .dll se ejecutan en el servidor y producen de forma dinámica la salida HTML de la página.
Ventajas que aportan las páginas de formularios Web Forms
La programación de aplicaciones Web presenta retos que no surgen normalmente en la programación tradicional de aplicaciones basadas en clientes. Entre estos retos se encuentran los siguientes:
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 y plenos de funcionalidad puede resultar difícil y tediosa de diseñar e implementar si se utilizan herramientas HTML básicas. Resulta particularmente difícil crear una interfaz de usuario enriquecida para aplicaciones que deban ejecutarse en muchos exploradores y plataformas de dispositivos clientes distintos.
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. Por lo tanto, las dos mitades de la aplicación comparten muy poca información; se pueden comunicar, pero normalmente intercambian sólo pequeñas porciones de información simple.
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. En otras palabras, los servidores no tienen memoria de las páginas que han procesado.
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. Este es a menudo el único origen de los errores en aplicaciones sometidas a un ciclo de crecimiento intenso.
ASP.NET tratan de solucionar estos temas de los modos siguientes:
Modelo de objetos coherente e intuitivo. El marco de trabajo de páginas ASP.NET presenta un modelo de objetos que permite concebir los formularios como una unidad, no como partes cliente y servidor independientes.
Modelo de programación controlado por eventos. Las páginas de formularios Web Forms aportan a las aplicaciones Web un modelo familiar que permite escribir controladores para los eventos que se producen en el cliente o en el servidor. El marco de trabajo de páginas ASP.NET compendia este modelo de tal modo que el mecanismo subyacente de captura de los eventos en el cliente, su transmisión al servidor y la llamada al método apropiado se realiza de modo automático e invisible para el implementador. El resultado es una estructura de código clara y escrita con facilidad, compatible con el desarrollo controlado por eventos.
Administración intuitiva de los estados. El marco de trabajo de páginas ASP.NET gestiona automáticamente las tareas de mantenimiento del estado del formulario y sus controles, y proporciona modos explícitos de mantener el estado de la información específica a la aplicación
Aplicaciones independientes del explorador. El marco de trabajo de páginas ASP.NET permite crear toda la lógica de la aplicación en el servidor, lo que elimina la necesidad de confeccionar código explícito para las diferencias de los exploradores.
Compatibilidad con Common Language Runtime de .NET Framework. El marco de trabajo de páginas ASP.NET es una tecnología de ASP.NET. ASP.NET se basa en .NET Framework, por lo que todo el marco de trabajo está disponible para cualquier aplicación ASP.NET
Rendimiento de servidor escalable de .NET Framework. El marco de trabajo de páginas ASP.NET permite escalar las aplicaciones Web de un equipo con un único procesador a una "batería de servidores Web" con varios equipos limpiamente y sin cambios complicados en la lógica de la aplicación.
Web.config._ 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, a menos que exista un web.config que en alguna de ellas, que sobrescriba los valores definidos por el web.config exterior.
Normalmente se tiene un web.config en el root del site ASP.NET.
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.
En tiempo de ejecución se pueden obtener los valores aquí definidos, mediante las clases que forman parte de la librería del Framework y se encuentran en el namespace System.Configuration.
Creando un Web Form con Visual Studio .NET
1. En la página 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 páginas HTML existentes:
1. En el explorador de soluciones, clic derecho sobre el proyecto, posicionarse en Agregar, y luego en Agregar Elemento existente
2. En la caja de diálogos de Nuevo Elemento Existente, posicionarse en donde se encuentra el archivo HTML, y clic en abrir.
3. 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 Página Web
ASP.NET provee dos modelos para administrar los elementos visuales y el código – un modelo single-file y otro modelo llamado code-behind. Los dos modelos funcionan iguales y usted puede usar los mismos controles y códigos en ambos modelos.
En el modelo single-file, el HTML y el código de programación se almacena en el mismo .aspx. El código de programación es un bloque que contiene el atributo runat=“server”, para marcar al código como código ejecutable por ASP.NET
En el modelo code-behind, el HTML esta en un archivo .aspx y el código de programación en otro archivo .aspx. En la versión 2.0, hay cambios significativos que hacen que el modelo code-behind sea mas robusto y mas fácil de trabajar.
El modelo Code-Behind
El modelo code-behind para el .NET Framework 2.0 toma ventaja de una nueva característica llamada Partial Classes. El archivo code-behind para la pagina no posee la definición completa de la clase. En su lugar, este incluye solo lo que sea necesario. El code-behind partial class no necesita instanciar variables o eventos explícitamente.
El vinculo entre el archivo .aspx y el archivo code-behind es similar al vinculo usado en el anterior modelo code-behind. Sin embargo, la directiva @ Page usa un nuevo atributo “CodeFile” en lugar del atributo “Code-behind” o “Src”. Además, la directiva incluye un atributo de herencia para especificar una class name para la pagina.
El archivo code-behind es mas simple. Este incluye solo el código escrito por usted mismo y casi ningún código generado. El archivo code-behind solo incluye el código que es necesario para soportar al diseño implementado.
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 HTML. Porque los eventos pueden ser deducidos desde los controles declarados, usted no necesita declarar nada en el método reservado InitializeComponent.
Mejor separación de código y contenido
Hace más fácil la separación del código y del HTML. En el modelo anterior de code-behind, no era práctico 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 páginas en capas sin necesitar tener que acceder a la página de code-behind
Que es el View State._ Técnicas utilizadas por ASP.NET para mantener el estado de los controles. 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. El área de trabajo de la página ASP.NET conserva ViewState en una variable de cadena que se envía al cliente y se recibe de vuelta de él como variable oculta. Cuando se produce la devolución, el área de trabajo de la página analiza la cadena de entrada de la variable oculta y establece la propiedad ViewState de cada control. Los programadores de controles deben tener en cuenta que todos los datos contenidos en ViewState recorren automáticamente un trayecto de ida y vuelta hasta el cliente. Estos trayectos suponen una carga adicional para el rendimiento, por lo que es importante hacer un uso razonable de ViewState. Si varias propiedades dependen de datos comunes, para optimizar el rendimiento puede conservar en ViewState únicamente los elementos clave. Cada control hereda de Control una propiedad denominada EnableViewState que permite a sus consumidores habilitar o deshabilitar la conservación de su ViewState.
Cache._ Cache es una tabla hash usada para almacenar los datos accedidos frecuentemente. La clase CacheDependency puede representar un único archivo o carpeta, o un conjunto de archivos o capetas, o un conjunto de items almacenados a un ítem en particular en la cache.
Controles._ Pueden ser de usuario y personalizados
Controles de usuarios: los controles de servidor ASP.NET proveen una gran cantidad de funcionalidades, pero estos no cubren todas las situaciones. Web User Controls lo habilita a definir controles de una manera muy sencilla para sus aplicaciones, utilizando la misma forma de programación que utiliza para escribir paginas Web. Usted puede convertir una página Web Form en un Web user control con pocas modificaciones, los user controls son identificados por la extensión de archivo .ascx.
Custom controls: los controles personalizados son componentes compilados que corren en el servidor y que encapsulan la información de los usuarios y/o objetos para que sean reutilizables. Los 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. Elementos HTML expuestos al servidor para que se puedan programar.
Controles de servidor Web. Controles con más funciones incorporadas que los controles de servidor HTML. 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: se tratan como texto opaco que se pasa al explorador. Sin embargo, cuando se convierten en controles de servidor HTML, los elementos HTML quedan expuestos como elementos programables en el servidor.
Los controles de servidor HTML ofrecen las funciones siguientes:
Un modelo de objetos que pueda volver a programar en el servidor con las técnicas habituales orientadas a objetos. Los controles de servidor exponen propiedades que permiten manipular los atributos HTML del control mediante programación en el código del servidor.
Un conjunto de eventos para los que pueda escribir controles de eventos de la misma forma que lo haría en un formulario basado en cliente, con la excepción de que un evento se controla en código del servidor.
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.
Paso a través de atributos personalizados. Pueden agregarse los atributos que se necesiten a un control de servidor HTML: el marco de trabajo de páginas los leerá y los procesará sin ningún cambio en la funcionalidad. Esto permite agregar atributos específicos del explorador a los controles.
Controles de servidor Web
Son un segundo conjunto de controles diseñado con otro enfoque. No se asignan uno a uno a controles de servidor HTML. En lugar de ello, 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. Por ejemplo, un control RadioButtonList de servidor Web podría procesarse en una tabla o como un texto en línea con otro HTML.
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.
Los controles de servidor Web ofrecen todas las funciones descritas anteriormente para los controles de servidor HTML (excepto la asignación uno a uno a elementos HTML) y estas funciones adicionales:
Un modelo de objetos enriquecido que proporciona capacidades de programación de tipo seguro.
Detección automática del explorador. Los controles pueden detectar capacidades del explorador y crear el resultado apropiado para exploradores básicos y enriquecidos (HTML 4.0).
Para algunos controles, la capacidad de definir su propia apariencia para el control mediante plantillas.
Para algunos controles, la capacidad de especificar si un evento del control provoca un envío inmediato al servidor o, en su lugar, se almacena en caché y se activa cuando se envía el formulario.
Capacidad para pasar eventos de un control anidado (como un botón en una tabla) al control contenedor.
Que es un control de usuario._ Los user controls son paginas ASP.NET con extensión ascx. Similar a las paginas Web Forms, usted puede editar estos controles con cualquier editor de texto o desarrollarlo usando code-behind clases. También, de manera similar a las paginas Web Forms, user controls son compilados cuando son pedidos por primera vez, y almacenados en memoria del servidor para reducir el tiempo de respuesta para peticiones sucesivas. A diferencia de la paginas Web Forms, los user control no pueden ser peticionados independientemente, deben ser incluidos en Web Forms para poder funcionar
Custom Controls
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. Pueden incluir todas las funciones de tiempo de diseño de los controles de servidor ASP.NET estándar, incluida la total compatibilidad con las funciones de diseño de Visual Studio, como la ventana Propiedades, el diseñador visual y el Cuadro de herramientas.
Hay varias formas de crear controles Web personalizados:
• Se puede compilar un control que combine la funcionalidad de dos o más controles existentes. Por ejemplo, si se necesita un control que encapsule un botón y un cuadro de texto, se puede crear compilando los controles existentes en uno.
• 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. Estas clases proporcionan toda la funcionalidad básica de los controles de servidor Web para que el usuario se pueda concentrar en programar las funciones necesarias.
Callbacks en Clientes._ XML-HTTP callbacks, o client callbacks, son más 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 Cliente
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.
