Secretos internos de ASP.NET – Parte I


Modelo de código

Tal
vez el cambio más obvio del funcionamiento interno de ASP.NET 2.0 esté
relacionado con cómo se crea una página Web ASP.NET. En esta sección,
examinaremos los cambios realizados al modelo de código subyacente y
cómo afectan estos cambios al desarrollo de ASP.NET.

Modelos de codificación en ASP.NET 1.x

En ASP.NET 1.x,
los desarrolladores tenían básicamente dos opciones para desarrollar un
formulario Web. En primer lugar, el desarrollador podía seguir el
modelo de ASP tradicional y escribir el código directamente en la
página ASPX. Este proceso, conocido como código en línea,
funciona muy bien cuando se trata de comandos sencillos. Sin embargo,
si el código es más complejo, la escritura de código en línea genera
páginas Web difíciles de leer que mezclan la presentación (HTML) con la
funcionalidad (código). En ASP.NET, se cambió la práctica de
codificación predeterminada para ayudar a resolver este problema. La
lógica empresarial y el código de control de eventos se podían escribir
en un archivo independiente que sólo incluía el código, denominado
archivo de código subyacente. El modelo de código subyacente
vincula un archivo de sólo código con el archivo ASPX que contiene las
etiquetas de presentación. Al separar el código de la presentación, los
equipos de desarrollo podían trabajar más rápido permitiendo a los
diseñadores trabajar en el archivo de presentación mientras los
desarrolladores trabajaban en el archivo de código.

Las principales
dificultades del modelo de código subyacente estaban relacionadas con
la manera en que era necesario sincronizar el archivo de código
subyacente con la página ASPX. Aunque la página ASPX se heredaba del
archivo de código subyacente desde el punto de vista de la
programación, los dos archivos estaban en realidad acoplados por una
relación más compleja.

Para obtener información más detallada acerca del modelo de código subyacente de ASP.NET 1.x, consulte el artículo de MSDN Library, Modelo de códigos de formularios Web Forms.

Complejidad de la herencia

El
paradigma del diseño de ASP.NET era que los desarrolladores utilizarían
Microsoft Visual Studio .NET para arrastrar y colocar controles en la
página ASPX. A continuación, Visual Studio generaría automáticamente el
código necesario correspondiente en el archivo de código subyacente. Si
se agregaban los controles a la página ASPX, era necesario agregar
nuevo código al archivo de código subyacente. Es decir, a pesar de que
la relación de herencia apunte en dirección contraria, la página ASPX
en realidad dirigiría el diseño del archivo de código subyacente.

Complejidad de la compilación

El
segundo problema de sincronización residía en la manera de compilar los
archivos. Todos los archivos de código subyacente, junto con todas las
clases necesarias, se compilaban en un ensamblado y se almacenaban en
el directorio /bin de la aplicación Web. El paso de compilación
se llevaba a cabo antes de la implementación de la aplicación. Por otra
parte, la página ASPX se compilaba en tiempo de ejecución la primera
vez que se solicitaba la página. El tiempo de ejecución de ASP.NET en
realidad compilaba la página ASPX en su propio ensamblado temporal.

El
problema de este proceso es que era posible cambiar la página ASPX sin
actualizar el ensamblado de código subyacente. Es decir, un
desarrollador podía decidir modificar una propiedad o cambiar el tipo
de un control en una página ASPX después de la implementación y no se
actualizaría el archivo de código subyacente ni se volvería a compilar
el ensamblado de la aplicación. Cuando ocurría esto, la aplicación
presentaría errores inesperados debido a la falta de coincidencia entre
los archivos de código subyacente y sus páginas ASPX asociadas.

Modelos de codificación en ASP.NET 2.0

ASP.NET
2.0 continúa ofreciendo tanto los modelos de código en línea como de
código subyacente. En lo que se refiere al modelo de código en línea,
hay muy pocos cambios salvo en la manera en que Microsoft Visual Studio
2005 admite el desarrollo de un único archivo. Para obtener más
detalles acerca de los cambios realizados en Visual Studio 2005 y cómo
maneja el código en línea, consulte este artículo (en inglés).

ASP.NET
2.0 resuelve tanto los problemas de herencia como de compilación del
modelo de código subyacente al modificar la naturaleza del archivo de
código subyacente. En ASP.NET 2.0, el archivo de código subyacente ya
no es una implementación completa de la clase System.Web.UI.Page. En su lugar, el archivo de código subyacente es una nueva construcción denominada clase parcial.
La clase parcial contiene todo el código definido por el usuario, pero
omite todo el código de estructura y conectividad que generaba
automáticamente Visual Studio .NET en ASP.NET 1.x. Cuando se
solicita una página ASPX con un nuevo archivo de código subyacente,
será el momento en que el tiempo de ejecución de ASP.NET 2.0 combine en
realidad la página ASPX y la clase parcial en una única clase, en vez
de en dos clases diferentes.

La clase parcial utiliza una nueva palabra clave (Expands en Visual Basic o Partial
en C#) para indicar que el código de la clase se debe combinar con otra
clase en tiempo de ejecución. De manera similar, la página ASPX utiliza
una nueva directiva denominada compilewith para indicar su asociación con el archivo de código subyacente.

Comparación de los archivos de código subyacente

Si ya está familiarizado con los archivos tradicionales de código subyacente de ASP.NET 1.x,
sabrá que Visual Studio inserta el código de inicialización y las
declaraciones de control generadas automáticamente. Este código
generado automáticamente es resultado directo de la sincronización
bidireccional entre el archivo de código subyacente y el archivo ASPX.
Una página ASPX típica con una etiqueta tendría su correspondiente
archivo de código subyacente que estaría compuesto de muchas líneas de
texto generado automáticamente.

Listado 1. Archivo de código subyacente en ASP.NET 1.x

namespace WebApplication1
{
public class WebForm1 : System.Web.UI.Page
{
protected System.Web.UI.WebControls.Label Label1;
private void Page_Load(object sender,
System.EventArgs e) { }
#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
InitializeComponent();
base.OnInit(e);
}
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
}
#endregion
}
}

El código generado automáticamente no sólo
define la etiqueta (línea en negrita), sino que también declara un
nuevo evento (la carga de la página) y conecta automáticamente el
evento con un contenedor de métodos generado automáticamente (Page_Load()).

En comparación, la misma página ASP.NET en ASP.NET 2.0 genera un archivo de código subyacente mucho más limpio.

Listado 2. Archivo de código subyacente en ASP.NET 2.0

namespace ASP {
public partial class Webform1_aspx
{
}
}

El desarrollador puede tener acceso a Label1 de manera automática y agregar todos los eventos necesarios. Por ejemplo, se puede agregar un evento Page_Load que inicialice la etiqueta.


Complejidad de la herencia

El
nuevo modelo de código subyacente reduce en gran medida la complejidad
de la herencia. Como la página ASPX no se hereda directamente del
archivo de código subyacente, ya no es necesario que este archivo
defina ni admita todos los controles definidos en la página ASPX. De
manera similar, el archivo de código subyacente puede obtener acceso
automáticamente a todos los controles de la página ASPX sin que sea
preciso el código de declaración, que era necesario en ASP.NET 1.x.
Todo esto es posible gracias a que el tiempo de ejecución de ASP.NET
inserta automáticamente la declaración necesaria y el código de
conexión de eventos en el archivo compilado final. Como el tiempo de
ejecución asume dicha responsabilidad, ni el desarrollador de código ni
el desarrollador Web deben preocuparse por ello.

Durante
el tiempo de diseño, esta vinculación la mantiene Visual Studio 2005.
El entorno de Visual Studio aprovecha el elemento de compilación del
tiempo de ejecución de ASP.NET para asegurarse de que el desarrollador
de código y el desarrollador Web puedan trabajar de forma sincronizada.

Complejidad de la compilación

Como
el nuevo archivo de código subyacente se une a la página ASPX y se
compila en una única clase completa en tiempo de ejecución, la
complejidad de la compilación desaparece. Es decir, el archivo de
código subyacente queda sincronizado automáticamente con la página
ASPX. Incluso con el nuevo modelo de compilación sigue siendo posible
tener código que no esté sincronizado, pero el problema puede
localizarse rápidamente ya que la excepción resultante es mucho más
explícita.

Aunque este
modelo tiene ventajas, también tiene dos inconvenientes básicos. En
primer lugar, las páginas ASPX deben implementarse en el sitio Web con
un formato humanamente legible. Si los desarrolladores utilizan el
modelo de código en línea, esto implica que toda la lógica
empresarial o parte de ella también se puede implementar en un servidor
de producción. Aunque IIS y ASP.NET están configurados para no exponer
las páginas ASPX sin procesar, un usuario malintencionado podría seguir
obteniendo acceso a los archivos mediante cualquier vulnerabilidad que
le permitiese tener acceso al servidor Web. En segundo lugar, la
primera vez que alguien solicite una página Web, la respuesta será más
lenta de lo normal, ya que el tiempo de ejecución de ASP.NET tendrá que
compilar la página ASPX.

El único control que tiene
un desarrollador sobre este proceso consiste en decidir si compila o no
por lotes las páginas ASPX. En ASP.NET 1.x, se puede configurar la compilación por lotes en el archivo web.config modificando la etiqueta <compilation>.

Listado 4. Configuración de la compilación por lotes

<compilation  
batch="true|false"
batchTimeout="number of seconds"
maxBatchSize="maximum number of pages per batched compilation"
maxBatchGeneratedFileSize="maximum combined size (in KB) of the
generated source file per batched compilation"
</compilation>

La compilación por lotes busca un equilibro,
respecto al tiempo de arranque para obtener un tiempo de carga
reducido, en la primera solicitud de una página Web. La otra ventaja de
la compilación por lotes es que todos los archivos ASPX se compilan en
un único ensamblado temporal en vez de compilar un ensamblado temporal
por página.


Compilación en ASP.NET 2.0

ASP.NET 2.0 ofrece cuatro modelos de compilación diferentes para una aplicación Web:

  • Normal (ASP.NET 1.x):
    en una aplicación Web ASP.NET normal, los archivos de código subyacente
    se compilaban en un ensamblado y se almacenaban en el directorio /bin.
    Las páginas Web (ASPX) se compilaban a medida que se solicitaban. Este
    modelo funcionaba correctamente para la mayoría de los sitios Web. Sin
    embargo, el proceso de compilación hacía que la primera solicitud de
    cualquier página ASP.NET fuera más lenta que las solicitudes
    posteriores. ASP.NET 2.0 continúa admitiendo este modelo de
    compilación.
  • Compilación por lotes: en ASP.NET 2.0, puede
    compilar por lotes cualquier aplicación con una única solicitud URL. Al
    igual que ocurría con ASP.NET 1.x, la compilación por lotes
    elimina la demora de la primera solicitud de página, pero crea un ciclo
    vital más largo durante el inicio. Además, la compilación por lotes
    sigue requiriendo que los archivos de código subyacente se compilen
    antes de la implementación.
  • Compilación antes de la implementación: una
    nueva característica de ASP.NET 2.0 que permite realizar la compilación
    completa del proyecto antes de la implementación. En la compilación
    completa, todos los archivos de código subyacente, las páginas ASPX,
    HTML, recursos gráficos y demás código de servidor se compilan en uno o
    más ensamblados ejecutables, dependiendo del tamaño de la aplicación y
    de la configuración de la compilación. Los ensamblados contienen todo
    el código compilado del sitio Web y los archivos de recursos y de
    configuración se copian sin modificación. Este método de compilación
    proporciona una seguridad y un rendimiento máximos, al precio de
    eliminar toda posibilidad de modificar el sitio Web tras su
    implementación. Si está trabajando con sitios Web muy seguros o muy
    visibles, esta opción es la mejor opción para la implementación final.
    Sin embargo, si está creando un pequeño sitio que se ejecuta en su
    intranet local y el sitio cambia con frecuencia, la precompilación
    completa puede ser una exageración.
  • Compilación completa en tiempo de ejecución:
    en el otro extremo de la compilación antes de la implementación,
    ASP.NET 2.0 proporciona un nuevo mecanismo para compilar toda la
    aplicación en tiempo de ejecución. Es decir, puede colocar los archivos
    de código subyacente sin compilar, así como todo el resto del código
    asociado, en el nuevo directorio de código y permitir que ASP.NET 2.0
    cree y mantenga las referencias al ensamblado que se generarán a partir
    de estos archivos en tiempo de ejecución. Esta opción ofrece la mayor
    flexibilidad en lo que se refiere a la modificación del contenido del
    sitio Web, pero al precio de almacenar el código sin compilar en el
    servidor.

Elegir la mejor opción de
compilación dependerá de sus circunstancias y necesidades concretas,
pero el modelo de compilación sigue siendo flexible. Incluso si decide
utilizar el directorio de código para almacenar los archivos de código
subyacente, podrá seguir implementando la aplicación mediante el método
de compilación completa.


Compilación por lotes

La
configuración de compilación por lotes de web.config sigue funcionando
en ASP.NET 2.0. Las ventajas de la compilación por lotes son que las
páginas están inmediatamente disponibles para el primer usuario y que
todos los errores de las páginas ASPX se detectarán durante la
compilación por lotes. Sin embargo, la compilación por lotes agrega un
retraso al inicio de la aplicación y se debe incluir en el archivo
web.config.

Compilación antes de la implementación

La
compilación antes de la implementación permite crear uno o varios
ensamblados que son una versión ejecutable del sitio Web. Los
ensamblados resultantes contienen el código compilado para el sitio
Web. Las páginas HTML, los recursos, los archivos de configuración y
las páginas ASPX se copian por separado.

La
compilación antes de la implementación requiere el uso de una utilidad
de línea de comandos denominada aspnet_compiler.exe. Esta utilidad crea
un directorio de implementación de destino que contiene un directorio /bin
con ensamblados y archivos auxiliares de las diferentes páginas ASPX.
También se puede utilizar esta utilidad para realizar una
precompilación en el lugar, lo que es similar a llamar a la "página
mágica". Los archivos auxiliares comparten los nombres de las páginas
ASPX, pero contienen código simple que llama al ensamblado compilado.
Es decir, las páginas ASPX son sencillamente armazones vacíos en vez de
páginas completamente funcionales.

Si se
precompila el sitio Web para su implementación, se consigue una mayor
seguridad ya que no es posible obtener acceso a parte alguna del código
sin descompilar el ensamblado. Para aumentar la protección, puede
proteger el ensamblado resultante y hacer que la aplicación Web sea
todavía más segura. Los principales inconvenientes de la compilación
antes de la implementación son que es necesario realizar estos pasos
antes de la implementación y que no se puede cambiar el sitio Web
después de que se haya implementado. Si quiere realizar cambios, deberá
compilar de nuevo el sitio Web y volver a implementarlo.

Para
la mayoría de las aplicaciones Web más importantes, la opción de
compilar antes de implementar será el mecanismo preferido para la
implementación, ya que reduce la cantidad de código sin procesar que se
implementa en el servidor Web y ofrece la mayor seguridad. El
incremento de proceso se puede incorporar al ciclo normal de
desarrollo/prueba/implementación sin ninguna perdida significativa de
productividad.

Compilación completa en tiempo de ejecución (el directorio de código)

En
los tres métodos de compilación descritos hasta ahora, era necesario
compilar todos los archivos de código (código subyacente y clases
necesarias) antes de la implementación. En ASP.NET 2.0 se dispone del
directorio de código.

El directorio de código es un
directorio especial que contiene las clases sin compilar. En tiempo de
ejecución, el tiempo de ejecución de ASP.NET compila el contenido de
este directorio en un ensamblado al que hacen referencia de manera
automática las páginas ASPX de la aplicación. Es decir, mediante el
directorio de código, puede evitar crear y hacer referencia a
ensamblados diferentes para el código necesario. La ventaja del
directorio de código es que puede realizar la implementación sin
compilar completamente el proyecto, lo que reduce por tanto los
posibles fallos de coincidencia. El inconveniente es que está
exponiendo potencialmente el código sin compilar en el servidor.

Esta
opción funciona mejor para las aplicaciones ASP.NET que no precisan una
gran cantidad de código necesario (ya sea en forma de archivos de
código subyacente o bien objetos externos). Para una aplicación
sencilla, la posibilidad de implementar y probar con rapidez el sistema
proporciona varias ventajas sobre otros métodos de compilación más
robustos.

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s