Modèles d’hébergement d’applications 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

Les applications Blazor peuvent être hébergées de l’une des façons suivantes :

• Côté client dans le navigateur sur WebAssembly.
• Côté serveur dans une application ASP.NET Core.

BlazorApplications WebAssembly

BlazorLes applications WebAssembly s’exécutent directement dans le navigateur sur un runtime .NET basé sur WebAssembly. BlazorLes applications WebAssembly fonctionnent de la même manière que les frameworks JavaScript front-end comme Angular ou React. Toutefois, au lieu d’écrire JavaScript, vous écrivez C#. Le runtime .NET est téléchargé avec l’application, ainsi que l’assembly d’application et toutes les dépendances requises. Aucun plug-in ou extension de navigateur n’est requis.

Les assemblys téléchargés sont des assemblys .NET normaux, comme vous les utiliseriez dans n’importe quelle autre application .NET. Étant donné que le runtime prend en charge .NET Standard, vous pouvez utiliser des bibliothèques .NET Standard existantes avec votre application BlazorWebAssembly. Toutefois, ces assemblys s’exécutent toujours dans le bac à sable de sécurité du navigateur. Certaines fonctionnalités peuvent lever un PlatformNotSupportedException, comme une tentative d’accéder au système de fichiers ou d’ouvrir des connexions réseau arbitraires.

Lorsque l’application se charge, le runtime .NET est démarré et pointé vers l’assembly de l’application. La logique de démarrage de l’application s’exécute et les composants racines sont rendus. Blazor calcule les mises à jour de l’interface utilisateur en fonction de la sortie rendue des composants. Les mises à jour du DOM sont ensuite appliquées.

BlazorLes applications WebAssembly s’exécutent purement côté client. Ces applications peuvent être déployées sur des solutions d’hébergement de sites statiques, comme GitHub Pages ou Azure Static Website Hosting. .NET n’est pas nécessaire sur le serveur. Un lien profond vers des parties de l’application nécessite généralement une solution de routage sur le serveur. La solution de routage redirige les demandes à la racine de l’application. Par exemple, cette redirection peut être gérée à l’aide de règles de réécriture d’URL dans IIS.

Pour obtenir tous les avantages de Blazor et du développement web .NET de pile complète, hébergez votre application BlazorWebAssembly avec ASP.NET Core. En utilisant .NET sur le client et le serveur, vous pouvez facilement partager du code et créer votre application à l’aide d’un ensemble cohérent de langages, de frameworks et d’outils. Blazor fournit des modèles pratiques pour configurer une solution qui contient à la fois une application BlazorWebAssembly et un projet hôte ASP.NET Core. Lorsque la solution est générée, les fichiers statiques générés à partir de l’application Blazor sont hébergés par l’application ASP.NET Core avec le routage de secours déjà configuré.

Applications serveur Blazor

Rappelez-vous de la discussion d’architecture Blazor ; les composants Blazor rendent leur sortie à une abstraction intermédiaire appelée RenderTree. L’infrastructure Blazor compare ensuite ce qui a été rendu avec ce qui a été rendu précédemment. Les différences sont appliquées au DOM. Les composants Blazor sont découplés de la façon dont leur sortie rendue est appliquée. Par conséquent, les composants eux-mêmes n’ont pas à s’exécuter dans le même processus que le processus mettant à jour l’interface utilisateur. En fait, ils n’ont même pas à s’exécuter sur la même machine.

Dans les applications serveur Blazor, les composants s’exécutent sur le serveur au lieu du côté client dans le navigateur. Les événements d’interface utilisateur qui se produisent dans le navigateur sont envoyés au serveur via une connexion en temps réel. Les événements sont distribués aux bonnes instances de composant. Le rendu des composants, et la différence calculée de l’interface utilisateur, est sérialisé et envoyé au navigateur où il est appliqué au DOM.

Le modèle d’hébergement serveur Blazor peut sembler familier si vous avez utilisé ASP.NET AJAX et le contrôle UpdatePanel. Le contrôle UpdatePanel gère l’application de mises à jour partielles de page en réponse au déclenchement d’événements sur la page. Lors du déclenchement, le UpdatePanel demande une mise à jour partielle, puis l’applique sans avoir à actualiser la page. L’état de l’interface utilisateur est géré à l’aide de ViewState. Les applications serveur Blazor sont légèrement différentes en cela que l’application nécessite une connexion active avec le client. En outre, l’état de l’interface utilisateur est conservé sur le serveur. En dehors de ces différences, les deux modèles sont conceptuellement similaires.

Comment choisir le modèle d’hébergement Blazor approprié

Comme décrit dans la documentation du modèle d’hébergement Blazor, les différents modèles d’hébergement Blazor ont des compromis différents.

Le modèle d’hébergement BlazorWebAssembly présente les avantages suivants :

• Il n’existe aucune dépendance côté serveur .NET. L’application fonctionne entièrement après le téléchargement sur le client.
• Les ressources et les fonctionnalités clientes sont entièrement exploitées.
• Le travail est déchargé du serveur vers le client.
• Un serveur web ASP.NET Core n’est pas nécessaire pour héberger l’application. Les scénarios de déploiement serverless sont possibles (par exemple, servir l’application à partir d’un CDN).

Les inconvénients du modèle d’hébergement BlazorWebAssembly sont les suivants :

• Les fonctionnalités du navigateur limitent l’application.
• Du matériel client et des logiciels compatibles (par exemple, la prise en charge de WebAssembly) sont requis.
• La taille du téléchargement est plus grande et les applications prennent plus de temps à se charger.
• La prise en charge du runtime et de l’outil .NET est moins mature. Par exemple, il existe des limitations dans la prise en charge et le débogage de .NET Standard.

À l’inverse, le modèle d’hébergement de serveur Blazor offre les avantages suivants :

• La taille du téléchargement est beaucoup plus petite qu’une application côté client et l’application se charge beaucoup plus rapidement.
• L’application tire pleinement parti des fonctionnalités de serveur, notamment l’utilisation de toutes les API compatibles .NET.
• .NET sur le serveur est utilisé pour exécuter l’application. Ainsi, les outils .NET existants, comme le débogage, fonctionnent comme prévu.
• Les clients légers sont pris en charge. Par exemple, les applications côté serveur fonctionnent avec les navigateurs qui ne prennent pas en charge WebAssembly et sur les appareils limités en ressources.
• La base de code .NET/C# de l’application, y compris le code du composant de l’application, n’est pas servie aux clients.

Les inconvénients du modèle d’hébergement serveur Blazor sont les suivants :

• Latence supérieure de l’interface utilisateur. Chaque interaction utilisateur implique un tronçon réseau.
• Il n’y a pas de prise en charge hors connexion. Si la connexion cliente échoue, l’application cesse de fonctionner.
• L’extensibilité est difficile pour les applications avec de nombreux utilisateurs. Le serveur doit gérer plusieurs connexions clientes et gérer l’état du client.
• Un serveur ASP.NET Core est requis pour servir l’application. Les scénarios de déploiement serverless ne sont pas possibles. Par exemple, vous ne pouvez pas servir l’application à partir d’un CDN.

La liste précédente de compromis peut être intimidante, mais votre modèle d’hébergement peut être modifié ultérieurement. Quel que soit le modèle d’hébergement Blazor sélectionné, le modèle de composant est identique. En principe, les mêmes composants peuvent être utilisés avec l’un ou l’autre modèle d’hébergement. Votre code d’application ne change pas ; toutefois, il est recommandé d’introduire des abstractions afin que vos composants restent indépendants du modèle. Les abstractions permettent à votre application d’adopter plus facilement un autre modèle d’hébergement.

Déployer votre application

Les applications ASP.NET Web Forms sont généralement hébergées sur IIS sur un ordinateur ou un cluster Windows Server. Les applications Blazor peuvent également :

• Être hébergées sur IIS, en tant que fichiers statiques ou en tant qu’application ASP.NET Core.
• Tirer parti de la flexibilité d’ASP.NET Core pour être hébergées sur différentes plateformes et infrastructures de serveur. Par exemple, vous pouvez héberger une application Blazor à l’aide de Nginx ou Apache sur Linux. Pour plus d’informations sur la publication et le déploiement d’applications Blazor, consultez la Blazordocumentation Hébergement et déploiement.

Dans la section suivante, nous allons examiner la façon dont les projets pour BlazorWebAssembly et les applications serveur Blazor sont configurés.

PrécédentSuivant