Comparaison des architectures ASP.NET Web Forms et Blazor

Conseil

Ce contenu est un extrait du livre électronique, Blazor pour les développeurs ASP NET Web Forms pour Azure, disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

Même si ASP.NET Web Forms et Blazor comptent de nombreux concepts similaires, leur fonctionnement présente des différences. Ce chapitre examine les rouages internes et les architectures d’ASP.NET Web Forms et de Blazor.

ASP.NET Web Forms

Le framework ASP.NET Web Forms est basé sur une architecture orientée 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 présentent les composants suivants :

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

Les contrôles sont des unités réutilisables de l’interface utilisateur web qui peuvent être placées et manipulées programmatiquement sur une page. Les pages sont composées de fichiers qui se terminent par .aspx et qui contiennent des balises, des contrôles et du code. Les classes code-behind sont dans des fichiers avec le même nom de base et une extension .aspx.cs ou .aspx.vb, selon le 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 balisage et livrés comme contrôles utilisateur. Un contrôle utilisateur dérive de la classe UserControl 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 aussi être générés intégralement avec le code en héritant de la classe de base WebControl ou CompositeControl.

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

Les contrôles d’une page sont généralement republiés sur la même page qui présentait le contrôle et ont avec eux le contenu d’un champ de formulaire masqué appelé ViewState. Le champ ViewState 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 changements du contenu soumis au serveur.

Blazor

Blazor est un framework d’interface utilisateur web côté client similaire à celui des frameworks front-end JavaScript comme Angular ou React. Blazor gère les interactions utilisateur et restitue les mises à jour nécessaires de l’interface utilisateur. Blazorn’est pas basé sur un modèle requête-réponse. Les interactions utilisateur sont gérées comme des événements qui ne sont pas dans le contexte d’une requête HTTP en particulier.

Les applications Blazor sont constituées d’un ou plusieurs composants racines qui sont restitués sur une page HTML.

La façon dont l’utilisateur spécifie où les composants doivent s’afficher et la façon dont les composants sont ensuite reliés pour les interactions utilisateur sont spécifiques au modèle d’hébergement.

Les composantsBlazorsont 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 englober le rendu d’autres composants. Les composants indiquent 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 suit ce qui a changé dans la sortie rendue. Les composants ne s’affichent pas directement dans le modèle DOM (Document Object Model). Ils s’affichent sur une représentation en mémoire du modèle DOM appelé RenderTree pour permettre à Blazor de suivre les modifications. Blazor compare la sortie qui vient d’être rendue à la sortie précédente pour générer un diff de l’interface utilisateur qu’il applique ensuite efficacement au modèle 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 SynchronizationContext pour appliquer un seul thread logique d’exécution. Les méthodes de cycle de vie d’un composant et les rappels d’événements qui sont déclenchés par Blazor sont exécutés sur ce SynchronizationContext.

PrécédentSuivant