Marcos de Desarrollo -...
-
Upload
truonghanh -
Category
Documents
-
view
228 -
download
0
Transcript of Marcos de Desarrollo -...
Marcos de DesarrolloDiseño e implementación de aplicaciones Web con .NET
Objetivos
Conocer la estructura de una aplicación Web ASP.NET
Saber escribir código que reaccione a eventos a nivel de aplicación
Conocer las opciones de configuración de una aplicación Web
Aprender a tratar excepciones en ASP.NET
Estructura de directorios de una aplicación Web ASP.NET
Directorio Descripción
Bin Contiene todos los ensamblados .NET precompilados
(normalmente DLLs) que usa la aplicación web ASP.NET (incluido
el de la propia aplicación)
App_Code Contiene ficheros de código fuente que se compilan
dinámicamente. Sólo se usa en Web Site (no en Web Project)
App_GlobalResources Archivos de recursos globales, accesibles a cada página en la
aplicación Web
App_LocalResources Archivos de recursos locales (accesibles desde su página)
App_WebRerefences Referencias a servicios web
App_Data Reservado para almacenamiento de datos (archivos de BD SQL
Server Express y archivos XML)
App_Browsers Definiciones de navegadores en XML. Definen las capacidades de
renderizado de cada navegador
App_Themes Temas usados por la aplicación
El archivo de aplicación Global.asaxDiseño e implementación de aplicaciones Web con .NET
Global.asax Permite escribir manejadores que reaccionan a eventos globales
de la aplicación No se puede solicitar el archivo Global.asax directamente. El código
se ejecuta automáticamente en respuesta a eventos
Los métodos de este archivo tienen nombres predefinidos
Sólo puede haber un archivo Global.asax por aplicación (aunque es opcional) y debe residir en el directorio raíz de la aplicación Para añadir: Add > New Item > Global Application Class
En una aplicación Web de tipo Web Project, VS creará: Global.asax
Global.asax.cs: código
Global.asax.cspublic class Global : System.Web.HttpApplication
{
protected void Application_Start(object sender, EventArgs e)
{
}
protected void Session_Start(object sender, EventArgs e)
{
}
protected void Application_BeginRequest(object sender, EventArgs e)
{
}
Global.asax.csprotected void Application_AuthenticateRequest(object sender,
EventArgs e)
{
}
protected void Application_Error(object sender, EventArgs e)
{
}
protected void Session_End(object sender, EventArgs e)
{
}
protected void Application_End(object sender, EventArgs e)
{
}
}
Eventos de la aplicación Se puede manejar dos tipos de eventos:
Los que ocurren siempre para cada request
Los que ocurren sólo bajo ciertas condiciones
Eventos de la aplicación por cada request
Extraído de (MacDonald, 2010)
Eventos de la aplicación por cada request
1. Application_BeginRequest(): se llama al comienzo de cada request
2. Application_AuthenticateRequest(): justo antes de que se realice la autenticación
3. Application_AuthorizeRequest(): después de que el usuario se autentique se determinan sus permisos
4. Application_ResolveRequestCache(): se usa comúnmente en conjunción con caché de salida (output caching). Con caché de salida, el HTML renderizado de un WFse reutiliza, sin ejecutar de nuevo su código. Sin embargo, este manejador de eventos sí se ejecuta
5. En este punto, la request es gestionada por el manejador apropiado. Por ejemplo, para una solicitud de un WF, este es el punto en el que se compila e instancia la página (si es necesario)
6. Application_AcquireRequestState(): se llama justo antes de que se recupere del cliente información específica de la sesión y se use para rellenar la colección Session
Eventos de la aplicación por cada request
7. Application_PreRequestHandlerExecute(): se llama antes de que el manejador HTTP apropiado ejecute la request
8. En este punto, el manejador apropiado ejecuta la request. Por ejemplo, si es una solicitud de un WF, se ejecuta el código para gestionar eventos de la página, y la página se renderiza a HTML
9. Application_PostRequestHandlerExecute(): se llama justo después de que la request sea manejada
10. Application_ReleaseRequestState(): se llama cuando la información de la sesión está a punto de ser serializada para que esté disponible para la próxima solicitud
11. Application_UpdateRequestCache(): se llama justo antes de que se añada información a la caché de salida. Por ejemplo, si se ha habilitado la caché de salida para una página, ASP.NET insertará el HTML renderizado para la página en la caché en este punto
12. Application_EndRequest se llama al final de la request, justo antes de que los objetos sean liberados
Eventos de la aplicación que no se disparan cada request
1. Application_Start(): se invoca cuando la aplicación arranca por primera vez y se crea el dominio de aplicación
Este es un lugar útil para proporcionar código de inicialización para la aplicación
2. Session_Start(): se invoca cada vez que se inicia una nueva sesión
Normalmente se utiliza para inicializar información específica del usuario
3. Application_Error(): se invoca si ocurre una excepción no controlada
4. Session_End(): se invoca si termina la sesión del usuario
Una sesión finaliza cuando el código la libera explícitamente o cuando expira después de que no se hayan recibido requests en un período de tiempo dado (normalmente 20 minutos)
Eventos de la aplicación que no se disparan cada request
5. Application_End(): se llama justo antes de que la aplicación termine
El fin de una aplicación puede ocurrir porque: se está reiniciando el IIS o porque la aplicación está transicionando a un nuevo dominio de aplicación (por ejemplo, en respuesta a una actualización de archivos)
6. Application_Disposed(): se invoca un poco después de que la aplicación haya sido apagada. El recolector de basura libera la memoria.
ASP.NET: ConfiguraciónDiseño e implementación de aplicaciones Web con .NET
Configuración ASP.NET La configuración de una aplicación ASP.NET se realiza
mediante archivos XML
Se pueden modificar en cualquier momento sin reiniciar la aplicación
Es fácil acceder a ellos y reemplazarlos (por ejemplo, por ftp)
Son fáciles de comprender y editar machine.config y web.config
machine.config Se ubica en:
c:\Windows\Microsoft.NET\Framework\[Version]\Config
Define secciones soportadas en ficheros de configuración, configura el proceso de ASP.NET, registra proveedores, etc. En el mismo directorio, se ubica un fichero web.config que
contiene configuración adicional Todas las aplicaciones web en la máquina heredan la configuración
en estos dos ficheros
Algunos de estos aspectos de configuración no aplican cuando se realiza el deploy a un servidor web IIS, que tiene su propio fichero de configuración: ApplicationHost.config
web.config Toda aplicación hereda la configuración del archivo machine.config y web.config raíz
Adicionalmente se puede aplicar configuración a cada aplicación individual
Para esto se puede incluir un archivo web.config en el directorio raíz de la aplicación Adicionalmente, es posible incluir archivos web.config en
los subdirectorios Interesante para definir distintas configuraciones de seguridad
ASP.NET usa herencia de configuración, de modo que cada subdirectorio adquiere la configuración de su directorio padre
Herencia de configuración
Extraído de (MacDonald, 2010)
web.config Web.config inicial (cuando se crea la aplicación)
<?xml version="1.0"?>
<configuration>
<system.web><compilation debug="true" targetFramework="4.0" />
</system.web>
</configuration>
Elementos <location> Es una extensión que permite especificar más de un grupo de opciones de configuración
en el mismo fichero de configuración
Con el atributo path se especifica el subdirectorio o archivo al que se le aplican las opciones de configuración
El siguiente ejemplo crea dos secciones de configuración, uno para el directorio actual y otro que aplica sólo a archivos en el subdirectorio Secure
<configuration><system.web>
<!-- la configuracion de ASP.NET va aqui --></system.web>
<location path="/Secure"><system.web>
<!-- las opciones de configuración para el subdirectorio Secure van aquí. -->
</system.web></location>
</configuration>
Elementos <system.web> Contiene todas las opciones de configuración específicas de ASP.NET. Seguridad, gestión
del estado, traceado, etc.
El esquema de esta sección es fijo (no se puede cambiar la estructura ni añadir elementos)
Elementos:
authentication, authorization, compilation, customErrors, membership, pages, profile, roleManager, sessionState, trace
Elemento <appSettings> Equivalente al mismo elemento en App.config
Define pares clave-valor
Permite actualizar configuración sin necesidad de recompilar
Útil para rutas de archivos, URL de servicios Web, etc.
Ejemplo:
<configuration>... <appSettings>
<!–- datos específicos de la aplicación van aquí. --><add key="websiteName" value="My New Website"/><add key="welcomeMessage"
value="Welcome to my new Website, friend!"/></appSettings>...
</configuration>
Elemento <appSettings> Se puede acceder con:
ConfigurationManager.AppSettings["clave"]
Ejemplo:
Label1.Text = ConfigurationManager.AppSettings["websiteName"]
Elemento <connectionStrings>
Define cadenas de conexión a base de datos
Acceso con ConfigurationManager.ConnectionStrings
<configuration><connectionStrings>
<add name="MiniBankConnString" connectionString="Data Source=.\SQLExpress;Initial
Catalog=minibank;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings><system.web> ... </system.web>
</configuration>
ConfigurationManager.ConnectionStrings["websiteName"].ToString();
Secciones personalizadas Existe la posibilidad de definir secciones
personalizadas
Se leen con:
Ejemplo:
ConfigurationSettings.GetSection("SECTION_NAME")
UnityConfigurationSection section =
(UnityConfigurationSection)ConfigurationManager.GetSection("unity");
Acceso mediante la clase Settings Se guardan en Web.config
Adicionalmente, VS crea el archivo Settings.settings, en la carpeta Propertiesde la aplicación
Se crea también un archivo Settings.Designer.cs, que incluye propiedades estáticas, que permiten acceder a las opciones de configuración de forma tipada
int count = Settings.Default.MiniBank_defaultCount;
Web.config
<?xml version="1.0"?>
<configuration>
<applicationSettings>
<Es.Udc.DotNet.MiniPortal.Properties.Settings>
<setting name="MiniBank_defaultCount" serializeAs="String">
<value>2</value>
</setting>
<setting name="MiniBank_applicationURL" serializeAs="String">
<value>http://localhost:8081/MiniBank</value>
</setting>
<Es.Udc.DotNet.MiniPortal.Properties.Settings>
</applicationSettings>
<system.web>
<trace enabled="true" localOnly="true" pageOutput="true" />
<compilation debug="true" />
<sessionState mode="InProc" cookieless="false" timeout="20" />
<customErrors mode="RemoteOnly" defaultRedirect="/errors/error.html">
<error statusCode="404" redirect="/errors/pagenotfound.html" />
</customErrors>
</system.web>
</configuration>
Páginas de ErrorDiseño e implementación de aplicaciones Web con .NET
Páginas de error La ejecución de una aplicación web puede originar excepciones
Controladas: las gestiona el código de usuario (e.g. IncorrectPasswordException, DuplicateInstanceException,...)
No controladas
Originadas por algún tipo de error interno
Acceso a base de datos
etc.
Encapsuladas como excepciones InternalErrorException
Páginas de error Página de error
ASP.NET permite definir una página a la que se redirecciona en caso de ocurrir una excepción no controlada
La página de error se puede definir en dos niveles: Página: atributo PageError
Aplicación: sección customErrors del Web.config
Páginas de errorDefinición a nivel de página
Atributo PageError
<%@ Page Language="C#" CodeBehind="Register.aspx.cs"
Inherits="Es.Udc.DotNet.MiniPortal.Web.Pages.User.Register"
PageError="InternalError.aspx" %>
Páginas de errorDefinición a nivel de aplicación
Sección customErrors del Web.config
<customErrors mode="RemoteOnly"
defaultRedirect="InternalError.aspx">
</customErrors>
Páginas de errorDefinición a nivel de aplicación Opciones atributo mode
On
Habilita los errores personalizados (<- suele utilizarse en producción)
Si no se especifica el atributo defaultRedirect, los usuarios verán un error genérico
Off
Deshabilita los errores personalizados (<- suele utilizarse en desarrollo)
Esto permite mostrar los errores detallados estándar
RemoteOnly
Especifica que los errores personalizados sólo deben mostrarse en los clientes remotos
Accediendo desde el servidor (en local) se muestran los errores de ASP.NET
Éste es el valor predeterminado
Páginas de errorDefinición a nivel de aplicación
Adicionalmente, en la sección customErrors se pueden personalizar las respuestas a códigos de estado HTTP:
<customErrors mode="RemoteOnly"
defaultRedirect="InternalError.aspx">
<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>
Bibliografía Recomendada:
M. MacDonald, A. Freeman, M. Szpuszta. Pro ASP.Net4 in C# 2010. 4th Ed. Apress. 2010.