Comparaison d’architecture de ASP.NET Web Forms et Blazor

Conseil / Astuce

Ce contenu est un extrait du livre électronique, Blazor pour les développeurs ASP NET Web Forms pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

Bien que ASP.NET Web Forms et Blazor aient de nombreux concepts similaires, il existe des différences dans leur fonctionnement. Ce chapitre examine les fonctionnements internes et les architectures de ASP.NET Web Forms et Blazor.

ASP.NET Web Forms

L’infrastructure ASP.NET Web Forms est basée sur une architecture centrée sur la page. Chaque requête HTTP pour un emplacement dans l’application est une page distincte avec laquelle ASP.NET répond. À mesure que les pages sont demandées, le contenu du navigateur est remplacé par les résultats de la page demandée.

Les pages se composent des composants suivants :

• Balisage HTML
• Code C# ou Visual Basic
• Classe code-behind contenant des fonctionnalités de logique et de gestion des événements
• Contrôles

Les contrôles sont des unités réutilisables de l’interface utilisateur web qui peuvent être placées par programme et interagir avec une page. Les pages sont composées de fichiers qui se terminent par .aspx contenant des balises, des contrôles et du code. Les classes code-behind se trouvent dans des fichiers portant le même nom de base et une extension .aspx.cs ou .aspx.vb , en fonction du langage de programmation utilisé. Il est intéressant de noter que le serveur web interprète le contenu des fichiers .aspx et les compile chaque fois qu’ils changent. Cette recompilation se produit même si le serveur web est déjà en cours d’exécution.

Les contrôles peuvent être générés avec le langage de balisage et remis en tant que contrôles d'utilisateur. Un contrôle utilisateur dérive de la UserControl classe et a une structure similaire à la page. Le balisage des contrôles utilisateur est stocké dans un fichier .ascx . Une classe code-behind associée réside dans un fichier .ascx.cs ou .ascx.vb . Les contrôles peuvent également être générés complètement avec du code, en héritant soit de la classe de base WebControl, soit de la classe de base CompositeControl.

Les pages ont également un cycle de vie d’événements étendu. Chaque page déclenche des événements pour l’initialisation, le chargement, le prérender et les événements de déchargement qui se produisent lorsque le runtime ASP.NET exécute le code de la page pour chaque requête.

Les contrôles sur une page effectuent généralement un postback vers la même page sur laquelle se trouve le contrôle, transportant avec eux une charge utile provenant d’un champ de formulaire masqué appelé ViewState. Le ViewState champ contient des informations sur l’état des contrôles au moment où ils ont été rendus et présentés sur la page, ce qui permet au runtime ASP.NET de comparer et d’identifier les modifications dans le contenu soumis au serveur.

Blazor

Blazor est une infrastructure d’interface utilisateur web côté client similaire par nature aux frameworks frontaux JavaScript comme Angular ou React. Blazor gère les interactions utilisateur et affiche les mises à jour nécessaires de l’interface utilisateur. Blazor n’est pas basé sur un modèle de demande-réponse. Les interactions utilisateur sont gérées en tant qu’événements qui ne se trouvent pas dans le contexte d’une requête HTTP particulière.

Blazor les applications se composent d’un ou plusieurs composants racines qui sont rendus sur une page HTML.

Comment l’utilisateur spécifie où les composants doivent s’afficher et comment les composants sont ensuite câblés pour les interactions utilisateur est un modèle d’hébergement spécifique.

Blazor les composants sont des classes .NET qui représentent un élément réutilisable de l’interface utilisateur. Chaque composant conserve son propre état et spécifie sa propre logique de rendu, qui peut inclure le rendu d’autres composants. Les composants spécifient des gestionnaires d’événements pour des interactions utilisateur spécifiques afin de mettre à jour l’état du composant.

Une fois qu’un composant gère un événement, Blazor affiche le composant et effectue le suivi de ce qui a changé dans la sortie rendue. Les composants ne s’affichent pas directement dans le dom (Document Object Model). Elles se rendent plutôt à une instance en mémoire du DOM appelée RenderTree afin que Blazor puisse suivre les modifications. Blazor compare la nouvelle sortie rendue à l'ancienne sortie pour calculer une différence d'interface utilisateur qu'elle applique ensuite efficacement au DOM.

Les composants peuvent également indiquer manuellement qu’ils doivent être rendus si leur état change en dehors d’un événement d’interface utilisateur normal. Blazor utilise un élément SynchronizationContext pour imposer un unique fil logique d’exécution. Les méthodes de cycle de vie d’un composant et tous les rappels d’événements déclenchés par Blazor sont exécutés sur ce SynchronizationContext.

PrécédentSuivant