Comparación de la arquitectura de ASP.NET Web Forms y Blazor

Sugerencia

Este contenido es un extracto del libro electrónico "Blazor for ASP.NET Web Forms Developers for Azure" (Blazor para desarrolladores de ASP.NET Web Forms), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Aunque ASP.NET Web Forms y Blazor tienen muchos conceptos similares, existen diferencias de funcionamiento. En este capítulo se examinan el funcionamiento interno y las arquitecturas de ASP.NET Web Forms y Blazor.

Formularios Web Forms ASP.NET

El marco ASP.NET Web Forms se basa en una arquitectura centrada en páginas. Cada solicitud HTTP de una ubicación en la aplicación es una página independiente con la que responde ASP.NET. A medida que se solicitan páginas, el contenido del explorador se reemplaza con los resultados de la página solicitada.

Las páginas tienen los componentes siguientes:

• Marcado HTML
• Código de C# o Visual Basic
• Una clase de código subyacente que contiene lógica y funciones de control de eventos
• Controles

Los controles son unidades reutilizables de la interfaz de usuario web que se pueden colocar y con los que se puede interactuar mediante programación en una página. Las páginas se componen de archivos que terminan en .aspx y contienen marcado, controles y código. Las clases de código subyacente se encuentran en archivos con el mismo nombre base y una extensión .aspx.cs o .aspx.vb, según el lenguaje de programación que se use. Curiosamente, el servidor web interpreta el contenido de los archivos .aspx y los compila cada vez que cambian. Esta recompilación se produce incluso si el servidor web ya está en ejecución.

Los controles se pueden crear con marcado y proporcionarse como controles de usuario. Un control de usuario se deriva de la clase UserControl y tiene una estructura similar a la página. El marcado de los controles de usuario se almacena en un archivo .ascx. Una clase de código subyacente adjunta se encuentra en un archivo .ascx.cs o .ascx.vb. Los controles también se pueden crear completamente con código, si se hereda de la clase base WebControl o CompositeControl.

Las páginas también tienen un ciclo de vida de eventos amplio. Cada página genera eventos para los eventos de inicialización, carga, representación previa y descarga que se producen cuando el entorno de ejecución de ASP.NET ejecuta el código de la página para cada solicitud.

Normalmente, los controles de una página se reenvían a la misma página que ha presentado el control y llevan una carga de un campo de formulario oculto denominado ViewState. El campo ViewState contiene información sobre el estado de los controles en el momento en que se han representado y presentado en la página, lo que permite que el entorno de ejecución de ASP.NET compare e identifique los cambios en el contenido que se envía al servidor.

Blazor

Blazor es un marco de interfaz de usuario web del lado cliente de naturaleza similar a plataformas de front-end de JavaScript como Angular o React. Blazor controla las interacciones del usuario y representa las actualizaciones necesarias de la interfaz de usuario. Blazorno se basa en un modelo de solicitud-respuesta. Las interacciones del usuario se controlan como eventos que no están en el contexto de una solicitud HTTP concreta.

Las aplicaciones Blazor constan de uno o más componentes raíz que se representan en una página HTML.

La forma en que el usuario especifica dónde se deben representar los componentes y cómo se conectan para las interacciones de usuario es específica del modelo de hospedaje.

Blazorcomponentes son clases de .NET que representan una pieza reutilizable de la UI. Cada componente mantiene su propio estado y especifica su propia lógica de representación, que puede incluir la representación de otros componentes. Los componentes especifican controladores de eventos para interacciones de usuario concretas a fin de actualizar el estado del componente.

Una vez que un componente controla un evento, Blazor representa el componente y realiza el seguimiento de lo que ha cambiado en la salida representada. Los componentes no se representan directamente en el Document Object Model (DOM). En su lugar, se representan en una representación en memoria del DOM denominada RenderTree para que Blazor pueda realizar el seguimiento de los cambios. Blazor compara la salida recién representada con la salida anterior para calcular una diferencia de interfaz de usuario que, después, se aplica de forma eficaz al DOM.

Los componentes también pueden indicar manualmente que se deben representar si su estado cambia fuera de un evento normal de la interfaz de usuario. Blazor usa un elemento SynchronizationContext para aplicar un único subproceso lógico de ejecución. Los métodos de ciclo de vida de un componente y todas las devoluciones de llamada de eventos que Blazor genere se ejecutan en dicho elemento SynchronizationContext.

AnteriorSiguiente