Modèles d’hébergement Blazor ASP.NET Core

Cet article explique les modèles d’hébergement Blazor, principalement centrés sur les applications Blazor Server et Blazor WebAssembly dans les versions de .NET antérieures à .NET 8. Les recommandations contenues dans cet article s’appliquent à toutes les versions de .NET pour les applications Blazor Hybrid qui s’exécutent sur des plateformes mobiles et de bureau natives. Les Blazor Web App dans .NET 8 ou les versions ultérieures sont mieux comprises en fonction de la manière dont les composants Razor sont rendus, ce que l’on appelle leur mode de rendu. Les modes de rendu sont brièvement abordés dans l’article de présentation Principes de base et traités en détail dans la section Modes de rendu BlazorASP.NET Core du nœud Composants.

Blazor est une infrastructure web permettant de créer des composants d’interface utilisateur web (composants Razor) pouvant être hébergés de différentes manières. Razorles composants peuvent s'exécuter côté serveur dans ASP.NET Core (Blazor Server) ou côté client dans le navigateur sur un runtime .NET basé sur WebAssembly (Blazor WebAssemblyBlazorWasm). Vous pouvez également héberger des composants Razor dans des applications mobiles et de bureau natives qui s’affichent sur un contrôle incorporé Web View (Blazor Hybrid). Quel que soit le modèle d’hébergement, la façon dont vous générez les Razor composants est la même. Les mêmes composants Razor peuvent être utilisés avec l’un des modèles d’hébergement inchangés.

Blazor Server

Avec le modèle d’hébergement Blazor Server, les composants sont exécutés sur le serveur à partir d’une application ASP.NET Core. Les mises à jour de l’interface utilisateur, la gestion des événements et les appels JavaScript sont gérés via une connexion SignalR à l’aide du protocole WebSockets. L’état sur le serveur associé à chaque client connecté est appelé circuit. Les circuits ne sont pas liés à une connexion réseau spécifique et peuvent tolérer des interruptions de réseau temporaires et des tentatives du client de se reconnecter au serveur lorsque la connexion est perdue.

Dans une application traditionnelle avec rendu serveur, l’ouverture de la même application dans plusieurs écrans de navigateur (onglets ou iframes) ne se traduit généralement pas par des demandes de ressources supplémentaires sur le serveur. Pour le modèle d’hébergement Blazor Server, chaque écran de navigateur nécessite un circuit distinct et des instances distinctes de l’état du composant géré par le serveur. Blazor envisage de fermer un onglet de navigateur ou d’accéder à une URL externe comme un arrêt normal. En cas d’arrêt normal, le circuit et les ressources associées sont immédiatement libérés. Un client peut également se déconnecter de manière non naturelle, par exemple en raison d’une interruption du réseau. Blazor Server stocke les circuits déconnectés pendant un intervalle configurable pour permettre au client de se reconnecter.

Côté client, le script Blazor établit la connexion SignalR avec le serveur. Le script est servi en tant qu’actif web statique avec compression automatique et fingerprinting.

Le modèle d’hébergement Blazor Server offre plusieurs avantages :

• La taille du téléchargement est nettement inférieure lorsque le modèle d’hébergement Blazor WebAssembly est utilisé, et l’application se charge beaucoup plus rapidement.
• L’application tire pleinement parti des fonctionnalités du serveur, notamment l’utilisation d’API .NET.
• .NET sur le serveur est utilisé pour exécuter l’application, de sorte que les outils .NET existants, tels que le débogage, fonctionnent comme prévu.
• Les clients légers sont pris en charge. Par exemple, Blazor Server fonctionne avec les navigateurs qui ne prennent pas en charge WebAssembly et sur les appareils aux ressources limitées.
• La base de code .NET/C# de l’application, y compris le code du composant de l’application, n’est pas servie aux clients.

Le modèle d’hébergement Blazor Server présente les limitations suivantes :

• Une latence plus élevée existe généralement. Chaque interaction utilisateur implique un tronçon réseau.
• Il n’y a pas de prise en charge hors connexion. Si la connexion client échoue, l’interactivité échoue.
• La mise à l’échelle d’applications avec de nombreux utilisateurs nécessite des ressources serveur pour gérer plusieurs connexions clients et l’état client.
• Un serveur ASP.NET Core est requis pour servir l’application. Les scénarios de déploiement serverless ne sont pas possibles, comme le service de l’application à partir d’un réseau de diffusion de contenu (CDN).

Nous vous recommandons d’utiliser le service Azure SignalR pour les applications adoptant le modèle d’hébergement Blazor Server. Le service permet d’effectuer un scale-up d’une application Blazor Server à un grand nombre de connexions simultanées SignalR.

Blazor WebAssembly

Le modèle d’hébergement Blazor WebAssembly exécute les composants côté client dans le navigateur sur un runtime .NET basé sur WebAssembly. Les composants Razor, leurs dépendances et le runtime .NET sont téléchargés dans le navigateur. Les composants sont exécutés directement sur le thread d’interface utilisateur du navigateur. Les mises à jour de l’interface utilisateur et la gestion des événements se produisent dans le même processus. Les ressources sont déployées sous forme de fichiers statiques sur un serveur ou un service web capable de diffuser du contenu statique aux clients.

Les Blazor Web App peuvent utiliser le modèle d’hébergement Blazor WebAssembly pour activer l’interactivité côté client. Lorsqu’une application est créée pour s’exécuter exclusivement avec le modèle d’hébergement Blazor WebAssembly sans rendu ni interactivité côté serveur, on parle d’application autonomeBlazor WebAssembly.

Une application Blazor WebAssembly générée en tant qu’application web progressive (PWA) utilise des API de navigateur modernes pour activer la plupart des fonctionnalités d’une application cliente native, telles que le fonctionnement hors connexion, l’exécution dans sa propre fenêtre d’application, le lancement à partir du système d’exploitation de l’hôte, la réception de notifications Push et la mise à jour automatique en arrière-plan.

Le script Blazor gère :

• Téléchargement du runtime .NET, des composants Razor et des dépendances.
• Initialisation du runtime.

La taille de l’application publiée, c’est-à-dire sa taille de charge utile, est un facteur de performance critique pour la facilité d’utilisation d’une application. Le téléchargement d’une application volumineuse dans un navigateur prend un certain temps, ce qui nuit à l’expérience utilisateur. Blazor WebAssembly optimise la taille de la charge utile pour réduire les temps de téléchargement :

• Le code inutilisé est retiré de l’application au moment de sa publication par l’éditeur de liens IL (langage intermédiaire).
• Réponses HTTP compressées.
• Le runtime .NET et les assemblys sont mis en cache dans le navigateur.

Le modèle d’hébergement Blazor WebAssembly offre plusieurs avantages :

• Pour les applications Blazor WebAssembly autonomes, il n’y a pas de dépendance au serveur .NET une fois l’application téléchargée depuis le serveur, ce qui permet à l’application de rester fonctionnelle même si le serveur devient indisponible.
• Les ressources et les fonctionnalités clientes sont entièrement exploitées.
• Le travail est déchargé du serveur vers le client.
• Pour les applications Blazor WebAssembly autonomes, un serveur web ASP.NET Core n’est pas requis pour héberger l’application. Les scénarios de déploiement serverless sont possibles, tels que le service de l’application à partir d’un réseau de diffusion de contenu (CDN).

Le modèle d’hébergement Blazor WebAssembly présente les limitations suivantes :

• Les composants Razor sont limités aux capacités du navigateur.
• 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 composants prennent plus de temps à se charger.
• Le code envoyé au client ne peut pas être protégé contre l’inspection ou les altérations par les utilisateurs.

L’interpréteur de Langage intermédiaire (IL) .NET inclut une prise en charge partielle du runtime juste-à-temps (JAT) pour améliorer les performances du runtime. L’interpréteur JAT optimise l’exécution des bytecodes d’interpréteur en les remplaçant par de petits objets blob du code WebAssembly. L’interpréteur JAT est automatiquement activé pour les applications Blazor WebAssembly, sauf lors du débogage.

Blazor prend en charge la compilation ahead-of-time (AOT), qui permet de compiler le code .NET directement en WebAssembly. La compilation AOT permet d’améliorer les performances du runtime au détriment d’une plus grande taille d’application. Pour en savoir plus, veuillez consulter la section Outils de build ASP.NET Core Blazor WebAssembly et compilation ahead-of-time (AOT).

Les mêmes outils de build .NET WebAssembly utilisés pour la compilation AOT relient également le runtime WebAssembly .NET pour découper le code inutilisé du runtime. Blazor élimine également le code inutilisé provenant des bibliothèques du framework .NET. Le compilateur .NET compresse en outre une application Blazor WebAssembly autonome pour réduire davantage la taille de la charge utile.

Les composants Razor rendus avec WebAssembly peuvent utiliser des dépendances natives conçues pour s’exécuter sur WebAssembly.

Blazor Hybrid

Blazor peut également être utilisé pour créer des applications clientes natives à l’aide d’une approche hybride. Les applications hybrides sont des applications natives qui tirent parti des technologies web pour leurs fonctionnalités. Dans une application Blazor Hybrid, les composants Razor s’exécutent directement dans l’application native (et non sur WebAssembly) ainsi que tout autre code .NET et affichent l’interface utilisateur web basée sur HTML et CSS vers un contrôle incorporé Web View via un canal d’interopérabilité local.

Les applications Blazor Hybrid peuvent être créées avec différents frameworks d’applications natives .NET, notamment .NET MAUI, WPF et Windows Forms. Blazor fournit des contrôles BlazorWebView pour ajouter des composants Razor aux applications créées avec ces frameworks. L’utilisation de Blazor avec .NET MAUI offre un moyen pratique de générer des applications multi-plateformes Blazor Hybrid pour les appareils mobiles et de bureau, tandis que l’intégration Blazor avec WPF et Windows Forms peut être un excellent moyen de moderniser des applications existantes.

Étant donné que les applications Blazor Hybrid sont natives, elles peuvent prendre en charge des fonctionnalités qui ne sont pas disponibles uniquement avec la plateforme web. Les applications Blazor Hybrid ont un accès complet aux capacités de la plateforme native via les API .NET classiques. Les applications Blazor Hybrid peuvent également partager et réutiliser des composants avec des applications Blazor Server ou Blazor WebAssembly existantes. Les applications Blazor Hybrid combinent les avantages du web, des applications natives et de la plateforme .NET.

Le modèle d’hébergement Blazor Hybrid offre plusieurs avantages :

• Réutilisez les composants existants qui peuvent être partagés sur les appareils mobiles, les appareils de bureau et le web.
• Tirez profit des compétences, de l’expérience et des ressources de développement web.
• Les applications ont un accès complet aux fonctionnalités natives de l’appareil.

Le modèle d’hébergement Blazor Hybrid présente les limitations suivantes :

• Des applications clientes natives distinctes doivent être générées, déployées et gérées pour chaque plateforme cible.
• La recherche, le téléchargement et l’installation des applications clientes natives prennent généralement plus de temps pour accéder à une application web dans un navigateur.

Pour plus d’informations, consultez ASP.NET Core Blazor Hybrid.

Pour plus d’informations sur les infrastructures clientes natives Microsoft, consultez les ressources suivantes :

• .NET Multi-platform App UI (.NET MAUI)
• Windows Presentation Foundation (WPF)
• Windows Forms

Quel modèle d’hébergement Blazor dois-je choisir ?

Le modèle d’hébergement d’un composant est défini par son mode de rendu, soit à la compilation soit dynamiquement à l’exécution, comme décrit dans la section Modes de rendu ASP.NET Core Blazor. Le tableau suivant présente les principaux critères à prendre en compte pour définir le mode de rendu afin de déterminer le modèle d’hébergement d’un composant. Pour les applications Blazor WebAssembly autonomes, tous les composants de l’application sont rendus côté client avec le modèle d’hébergement Blazor WebAssembly.

Les applications Blazor Hybrid incluent des applications créées avec les frameworks .NET MAUI, WPF et Windows Forms.

Feature	Blazor Server	Blazor WebAssembly (Wasm)	Blazor Hybrid
Compatibilité complète avec les API .NET	✔️Supported	❌ Non pris en charge	✔️Supported
Accès direct aux ressources serveur et réseau	✔️Supported	❌ Non pris en charge†	❌ Non pris en charge†
Petite taille de la charge utile avec un temps de chargement initial rapide	✔️Supported	❌ Non pris en charge	❌ Non pris en charge
Vitesse d’exécution quasi native	✔️Supported	✔️Supported‡	✔️Supported
Code d’application sécurisé et privé sur le serveur	✔️Supported	❌ Non pris en charge†	❌ Non pris en charge†
Exécuter des applications hors connexion une fois téléchargées	❌ Non pris en charge	✔️Supported	✔️Supported
Hébergement de site statique	❌ Non pris en charge	✔️Supported	❌ Non pris en charge
Décharge le traitement vers les clients	❌ Non pris en charge	✔️Supported	✔️Supported
Accès complet aux fonctionnalités du client natif	❌ Non pris en charge	❌ Non pris en charge	✔️Supported
Déploiement basé sur le web	✔️Supported	✔️Supported	❌ Non pris en charge

Les applications Blazor WebAssembly† et Blazor Hybrid peuvent utiliser des API basées sur le serveur pour accéder aux ressources serveur/réseau et accéder au code d’application privé et sécurisé.
‡Blazor WebAssembly atteint uniquement les performances quasi natives avec la compilation anticipée (AOT).

Après avoir choisi le modèle d’hébergement de l’application, vous pouvez générer une application Blazor Server ou Blazor WebAssembly à partir d’un modèle de projet Blazor. Pour plus d’informations, consultez Outils pour ASP.NET Core Blazor.

Pour créer une application Blazor Hybrid, consultez les articles sous tutoriels Blazor Hybrid ASP.NET Core.

Compatibilité complète de l’API .NET

Les composants rendus pour le modèle d’hébergement Blazor Server et les applications Blazor Hybrid ont une compatibilité complète avec les API .NET, tandis que les composants rendus pour Blazor WebAssembly sont limités à un sous-ensemble d’API .NET. Lorsque les spécifications d’une application nécessitent une ou plusieurs API .NET indisponibles pour les composants rendus avec WebAssembly, choisissez de rendre les composants pour Blazor Server ou utilisez Blazor Hybrid.

Accès direct aux ressources serveur et réseau

Les composants rendus avec le modèle d’hébergement Blazor Server ont un accès direct aux ressources serveur et réseau sur lesquelles l’application s’exécute. Étant donné que les composants hébergés avec Blazor WebAssembly ou Blazor Hybrid s’exécutent sur un client, ils n’ont pas d’accès direct aux ressources serveur et réseau. Les composants peuvent accéder aux ressources serveur et réseau indirectement via des API serveur protégées. Les API basées sur le serveur peuvent être disponibles via des bibliothèques, packages et services tiers. Prenez en compte les considérations suivantes :

• Les bibliothèques, packages et services tiers peuvent être coûteux à implémenter et à gérer, être faiblement pris en charge ou présenter des risques en matière de sécurité.
• Si une ou plusieurs API basées sur le serveur sont développées en interne par votre organisation, des ressources supplémentaires sont nécessaires pour les créer et les gérer.

Utilisez le modèle d’hébergement Blazor Server pour éviter d’exposer des API depuis l’environnement serveur.

Petite taille de la charge utile avec un temps de chargement initial rapide

Le rendu des composants côté serveur réduit la taille de la charge utile de l’application et améliore les temps de chargement initiaux. Lorsque des temps de chargement initiaux rapides sont souhaités, utilisez le modèle d’hébergement Blazor Server ou envisagez un rendu statique côté serveur.

Vitesse d’exécution quasi native

Les applications Blazor Hybrid s’exécutent à l’aide du runtime .NET en mode natif sur la plateforme cible, ce qui offre la meilleure vitesse possible.

Les composants rendus avec le modèle d’hébergement Blazor WebAssembly, y compris les Progressive Web Apps (PWA), et les applications Blazor WebAssembly autonomes s’exécutent avec le runtime .NET pour WebAssembly, ce qui est plus lent que l’exécution directe sur la plateforme. Envisagez d’utiliser la compilation ahead-of-time (AOT) pour améliorer les performances d’exécution avec Blazor WebAssembly.

Code d’application sécurisé et privé sur le serveur

Le maintien du code applicatif sécurisé et privé sur le serveur est une fonctionnalité intégrée aux composants rendus avec le modèle d’hébergement Blazor Server. Les composants rendus avec les modèles d’hébergement Blazor WebAssembly ou Blazor Hybrid peuvent utiliser des API serveur pour accéder à des fonctionnalités devant rester privées et sécurisées. Les considérations relatives au développement et à la maintenance des API basées sur le serveur décrites dans la section Accès direct aux ressources serveur et réseau s’appliquent. Si le développement et la maintenance d’API serveur ne sont pas souhaités pour garantir la confidentialité et la sécurité du code, utilisez le modèle d’hébergement Blazor Server.

Exécutez des applications hors connexion une fois téléchargées

Les applications Blazor WebAssembly autonomes générées en tant qu’application web progressive (PWA) et les applications Blazor Hybrid peuvent s’exécuter hors connexion, ce qui est particulièrement utile lorsque les clients ne sont pas en mesure de se connecter à Internet. Les composants rendus avec le modèle d’hébergement Blazor Server ne fonctionnent pas si la connexion au serveur est perdue. Si l’application doit fonctionner hors ligne, les options à privilégier sont les applications Blazor WebAssembly autonomes et les Blazor Hybrid.

Hébergement de site statique

L’hébergement sur site statique est possible avec les applications Blazor WebAssembly autonomes car elles sont téléchargées vers les clients sous forme de fichiers statiques. Les applications Blazor WebAssembly autonomes ne nécessitent pas de serveur pour exécuter du code côté serveur et peuvent être diffusées via un réseau de distribution de contenu (CDN) (par exemple, Azure CDN).

Bien que les applications Blazor Hybrid soient compilées en une ou plusieurs ressources de déploiement autonomes, les ressources sont généralement fournies aux clients par le biais d’une boutique d’applications tiers. Si l’hébergement statique est une exigence de l’application, choisissez une application Blazor WebAssembly autonome.

Décharge le traitement vers les clients

Les applications Blazor WebAssembly et Blazor Hybrid s’exécutent sur les clients et déchargent ainsi le traitement vers les clients. Les applications Blazor Server s’exécutent sur un serveur, de sorte que la demande de ressources serveur augmente généralement avec le nombre d’utilisateurs et la quantité de traitement requise par utilisateur. Lorsqu’il est possible de décharger la plupart ou la totalité du traitement d’une application vers des clients et que l’application traite une quantité importante de données, Blazor WebAssembly ou Blazor Hybrid est le meilleur choix.

Accès complet aux fonctionnalités du client natif

Les applications Blazor Hybrid disposent d’un accès complet aux fonctionnalités de l’API client native via les infrastructures d’application natives .NET. Dans les applications Blazor Hybrid, les composants Razor s’exécutent directement dans l’application native, et non sur WebAssembly. Lorsque des fonctionnalités client complètes sont requises, Blazor Hybrid est le meilleur choix.

Déploiement basé sur le web

Les Blazor Web App sont mis à jour lors du prochain rafraîchissement de l’application dans le navigateur.

Les applications Blazor Hybrid sont des applications clientes natives qui nécessitent généralement un programme d’installation et un mécanisme de déploiement spécifique à la plateforme.

Définir le modèle d’hébergement d’un composant

Pour définir le modèle d’hébergement d’un composant comme Blazor Server ou Blazor WebAssembly à la compilation ou dynamiquement à l’exécution, vous devez définir son mode de rendu. Les modes de rendu sont expliqués et illustrés en détail dans l’article Modes de rendu ASP.NET Core Blazor. Nous ne recommandons pas d'aller directement à l’article Modes de rendu sans avoir consulté au préalable les articles situés entre celui-ci et l’article actuel. Par exemple, les modes de rendu sont plus faciles à comprendre en examinant des exemples de composants Razor, mais la structure et la fonction de base des composants Razor ne sont abordées que dans l’article Principes de base ASP.NET Core Blazor. Il est également utile de se familiariser avec les modèles de projet et les outils de Blazor avant de travailler avec les exemples de composants de l’article Modes de rendu.