Comparación de 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 en el funcionamiento. En este capítulo se examinan los trabajos internos y las arquitecturas de ASP.NET Web Forms y Blazor.

formularios web de ASP.NET

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

Las páginas constan de los siguientes componentes:

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

Los controles son unidades reutilizables de la interfaz de usuario web que se pueden colocar e interactuar mediante programación con en una página. Las páginas se componen de archivos que terminan con .aspx que contienen marcado, controles y código. Las clases de código subyacente están en archivos con el mismo nombre base y una extensión .aspx.cs o .aspx.vb , según el lenguaje de programación usado. Interesantemente, 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 se está ejecutando.

Los controles se pueden compilar con marcado y entregarse como controles de usuario. Un control de usuario se deriva de la UserControl clase y tiene una estructura similar a page. El marcado de los controles de usuario se almacena en un archivo .ascx . Una clase de código subyacente que acompaña reside en un archivo .ascx.cs o .ascx.vb . Los controles también se pueden construir completamente con código, heredando de la clase base WebControl o CompositeControl.

Las páginas también tienen un amplio ciclo de vida de eventos. Cada página genera eventos para los eventos de inicialización, carga, representación previa y descarga que se producen a medida que el tiempo 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 ViewState campo contiene información sobre el estado de los controles en el momento en que se representaron y presentaron en la página, lo que permite que el entorno de ejecución de ASP.NET compare e identifique los cambios en el contenido enviado al servidor.

Blazor

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

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

Cómo el usuario especifica dónde se deben representar los componentes y cómo se conectan los componentes para las interacciones del usuario es específico del modelo de hospedaje .

Blazor los componentes son clases de .NET que representan una parte reutilizable de la interfaz de usuario. 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 específicas para actualizar el estado del componente.

Después de que un componente controle un evento, Blazor representa el componente y realiza un seguimiento de lo que ha cambiado en la salida representada. Los componentes no se representan directamente en el Modelo de objetos de documento (DOM). En su lugar, se representan en una representación en memoria del DOM denominada RenderTree para que Blazor pueda seguir los cambios. Blazor compara la salida recién representada con la salida anterior para calcular una diferencia de interfaz de usuario que, a continuación, se aplica eficazmente al DOM.

Los componentes también pueden indicar manualmente que deben representarse si su estado cambia fuera de un evento de interfaz de usuario normal. 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.

Siguiente anterior