Páginas
Las páginas de ASP.NET, conocidas oficialmente como "web forms" (formularios web), son el principal medio de construcción para el desarrollo de aplicaciones web.8 Los formularios web están contenidos en archivos con una extensión ASPX; en jerga de programación, estos archivos típicamente contienen etiquetas HTML o XHTML estático, y también etiquetas definiendo Controles Web que se procesan del lado del servidor yControles de Usuario donde los desarrolladores colocan todo el código estático y dinámico requerido por la página web. Adicionalmente, el código dinámico que se ejecuta en el servidor puede ser colocado en una página dentro de un bloque
ASP.NET sólo funciona sobre el servidor de Microsoft IIS, lo que supone una desventaja respecto a otros lenguajes del lado de servidor, ejecutables sobre otros servidores más populares como Apache. Ejemplos de esto son PHP, Perl o Python.
<% -- código dinámico -- %>
que es muy similar a otras tecnologías de desarrollo como PHP, JSP y ASP, pero esta práctica es, generalmente, desaconsejada excepto para propósitos de enlace de datos pues requiere más llamadas cuando se genera la página.ASP.NET sólo funciona sobre el servidor de Microsoft IIS, lo que supone una desventaja respecto a otros lenguajes del lado de servidor, ejecutables sobre otros servidores más populares como Apache. Ejemplos de esto son PHP, Perl o Python.
Formulario web de ejemplo
Este es un ejemplo que utiliza código "en línea", opuesto al código independiente (code-behind).
<%@ Page Language="C#" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <script runat="server"> protected void Page_Load(object sender, EventArgs e) { Label1.Text = DateTime.Now.ToLongDateString(); } </script> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>Página de Ejemplo</title> </head> <body> <form id="form1" runat="server"> <div> <asp:Label runat="server" id="Label1" /> </div> </form> </body> </html>
El modelo Code-behind
Microsoft recomienda que para realizar programación dinámica se use el modelo code-behind, o de respaldo, que coloca el código en un archivo separado o en una etiqueta de script especialmente diseñada. Los nombres de los archivos code-behind están basados en el nombre del archivo ASPX tales como MiPagina.aspx.cs o MiPagina.aspx.vb (esta práctica se realiza automáticamente en Microsoft Visual Studio y otros entornos de desarrollo). Cuando se usa este estilo de programación, el desarrollador escribe el código correspondiente a diferentes eventos, como la carga de la página, o el clic en un control, en vez de un recorrido lineal a través del documento.
El modelo code-behind de ASP.NET marca la separación del ASP clásico y alienta a los desarrolladores a construir aplicaciones con la idea de presentación y contenido separados en mente. En teoría, esto permite a un diseñador web, por ejemplo, enfocarse en la creación del diseño con menos posibilidades de alterar el código de programación mientras lo hace. Esto es similar a la separación en el Modelo Vista Controlador
Ejemplo
<%@ Page Language="C#" CodeFile="EjemploCodeBehind.aspx.cs" Inherits="SitioWeb.EjemploCodeBehind" AutoEventWireup="true" %>
La etiqueta superior es colocada al inicio del archivo ASPX. La propiedad CodeFile de la directiva @ Page especifica qué archivo (.cs o .vb) contiene el código code-behind mientras que la propiedad Inherits especifica la clase de la cual deriva la página. En este ejemplo, la directiva @ Page está incluida en EjemploCodeBehind.aspx y el archivo EjemploCodeBehind.aspx.cs contendrá el código para esta página:
using System; namespace SitioWeb { public partial class EjemploCodeBehind: System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } } }
En este caso, el método Page_Load() será llamado cada vez que la página ASPX sea solicitada al servidor. El programador puede implementar manejadores de eventos en varias etapas del proceso de ejecución de la página..
Controles de usuario
ASP.NET permite la creación de componentes reutilizables a través de la creación de Controles de Usuario (User Controls). Un control de usuario sigue la misma estructura que un formulario web, excepto que los controles derivan de la clase
System.Web.UI.UserControl
, y son almacenados en archivos ASCX. Como los archivos ASPX, un ASCX contiene etiquetas HTML o XHTML, además de etiquetas para definir controles web y otros controles de usuario. También pueden usar el modelo code-behind.
Los programadores pueden agregar sus propias propiedades y métodos,9 y manejadores de eventos.10 Un mecanismo de eventos en burbuja proporciona la capacidad de pasar un evento disparado por un control de usuario a la página que lo contiene .
Administración del estado
Las aplicaciones ASP.NET son alojadas en un servidor web y se tiene acceso a ellas mediante el protocolo sin estado HTTP, que no guarda ninguna información sobre conexiones anteriores. Por lo tanto, si la aplicación requiere interacción entre conexiones, tiene que implementar su propia administración del estado. ASP.NET proporciona varias maneras de administrar el estado de las aplicaciones ASP.NET.
Estado de la aplicación
El estado de la aplicación (Application state) es una colección de variables definidas por el usuario que son compartidas por todas las invocaciones de una aplicación ASP.NET. Estas son establecidas e inicializadas cuando el evento
Application_OnStart
se dispara en la carga de la primera instancia de las aplicaciones y están disponible hasta que la última instancia termina. Las variables de estado o variables de sesión de la aplicación son identificadas por nombres.11Estado de la sesión
El estado de la sesión (Session state) es una colección de variables definidas por el usuario, las cuales persisten durante la sesión de un usuario. Estas variables son únicas para diferentes instancias de una sesión de usuario, y son accedidas usando la colección
Session
. Las variables de sesión pueden ser preparadas para ser automáticamente destruidas después de un determinado tiempo de inactividad, incluso si la sesión no ha terminado. Del lado del cliente, una sesión de usuario es identificada por una cookie o codificando el ID de la sesión en la misma URL.11
ASP.NET proporciona tres modos de persistencia para variables de sesión:11
- InProc
- Las variables de sesión son mantenidas dentro del proceso. Sin embargo, en este modo, las variables son destruidas cuando el proceso ASP.NET es reciclado o terminado.
- StateServer
- En este modo, ASP.NET ejecuta un servicio de Windows separado que mantiene las variables de estado. Como esta administración de estado ocurre fuera del proceso ASP.NET, tiene un impacto negativo en el rendimiento, pero permite a múltiples instancias de ASP.NET compartir el mismo estado del servidor, permitiendo que una aplicación ASP.NET pueda tener su carga balanceada y escalada en múltiples servidores. También, como el servicio de administración del estado se ejecuta independiente de ASP.NET, las variables pueden persistir a través de las finalizaciones del proceso ASP.NET.
- SqlServer
- En este modo, las variables de estado son almacenadas en un servidor de base de datos, accesible usando SQL. Las variables de sesión pueden persistir a través de finalizaciones de procesos también en este modo.
No hay comentarios:
Publicar un comentario