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

Cet article explique les modèles d’hébergement Blazor, principalement axés sur les applications Blazor Server et Blazor WebAssembly dans les versions de .NET antérieures à .NET 8. L’aide apportée dans cet article est pertinente dans 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 version ultérieure sont mieux conceptualisées par le rendu des composants Razor, qui est décrit comme leur mode de rendu. Les modes d’affichages sont brièvement abordés dans l’article de vue d’ensemble des principes de base et abordés en détail dans les modes d’affichage Blazor ASP.NET Core du nœud de composants.

Blazor est une infrastructure web permettant de créer des composants d’interface utilisateur web (Razor composants) qui peuvent être hébergés de différentes manières. Les composants Razor peuvent s’exécuter côté serveur dans ASP.NET Core (Blazor Server) et côté client dans le navigateur sur un runtime .NET basé sur WebAssembly (Blazor WebAssembly, WASM Blazor). 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 depuis 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 managé 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.

Sur le client, le script Blazor établit la connexion SignalR avec le serveur. Le script est servi à partir d’une ressource incorporée dans l’infrastructure partagée ASP.NET Core.

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

• La taille du téléchargement est beaucoup plus petite que 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 Core.
• .NET Core 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, Blazor Server fonctionne 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.

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 SignalR Azure pour les applications qui adoptent 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 des 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 sur 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 en tant que fichiers statiques sur un serveur web ou un service capable de fournir un contenu statique aux clients.

Les applications web Blazor peuvent utiliser le modèle d’hébergement Blazor WebAssembly pour activer l’interactivité côté client. Lorsqu’une application qui s’exécute exclusivement sur le modèle d’hébergement Blazor WebAssembly sans rendu et interactivité côté serveur est créée, elle est appelée application Blazor WebAssembly autonome.

Lorsqu’une application autonome Blazor WebAssembly utilise une application backend ASP.NET Core pour servir ses fichiers, l’application est appelée application Blazor WebAssemblyhébergée. À l’aide de l’hébergement Blazor WebAssembly, vous bénéficiez d’une expérience de développement web complète avec .NET, notamment la possibilité de partager du code entre les applications client et serveur, la prise en charge du pré-rendu et l’intégration avec MVC et Pages Razor. Une application client hébergée peut interagir avec son application serveur back-end sur le réseau à l’aide d’une variété d’infrastructures et de protocoles de messagerie, tels que l’API web, gRPC-web et SignalR (Utilisez ASP.NET Core SignalR avec Blazor).

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 :

• Le téléchargement du runtime .NET, des composants Razor et des dépendances du composant.
• L’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’existe aucune dépendance côté serveur .NET après le téléchargement de l’application depuis le serveur. L’application reste donc fonctionnelle si le serveur est hors connexion.
• 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 autonomes Blazor WebAssembly, il n’est pas nécessaire d’avoir un serveur web ASP.NET Core 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 fonctionnalité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 le chargement des composants prend plus de temps.
• Le code envoyé au client ne peut pas être protégé contre l’inspection et la falsification 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 anticipée (AOT), qui vous permet de compiler votre code .NET directement dans WebAssembly. La compilation AOT permet d’améliorer les performances du runtime au détriment d’une plus grande taille d’application. Pour plus d’informations, consultez Outils de génération ASP.NET Core Blazor WebAssembly et compilation AOT (ahead-of-time).

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 supprime également le code inutilisé des bibliothèques d’infrastructure .NET. Le compilateur .NET pré-comprime en outre une application Blazor WebAssembly autonome afin d'en réduire la charge utile.

Les composants rendus par WebAssembly Razor peuvent utiliser les dépendances natives générées pour s’exécuter sur WebAssembly.

Blazor Hybrid

Blazor peut également être utilisé pour générer 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 générées à l’aide de différentes infrastructures d’applications natives .NET, notamment .NET MAUI, WPF et Windows Forms. Blazor fournit des contrôles BlazorWebView permettant d’ajouter des composants Razor aux applications générées avec ces infrastructures. 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 fonctionnalités de plateforme natives via les API .NET normales. 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 au moment de la compilation, soit au moment de l’exécution, qui est décrit avec des exemples dans Modes de rendu Blazor ASP.NET Core. Le tableau suivant présente les principales considérations relatives à la définition du mode de rendu pour déterminer le modèle d’hébergement d’un composant. Pour les applications autonomes Blazor WebAssembly, tous les composants de l’application sont rendus sur le client avec le modèle d’hébergement Blazor WebAssembly.

Les applications Blazor Hybrid incluent .NET MAUI, WPF et les applications d’infrastructure Windows Forms.

Fonctionnalité	Blazor Server	Blazor WebAssembly (WASM)	Blazor Hybrid
Compatibilité complète de l’API .NET	✔️Pris en charge	❌Non pris en charge	✔️Pris en charge
Accès direct aux ressources serveur et réseau	✔️Pris en charge	❌Non pris en charge†	❌Non pris en charge†
Petite taille de la charge utile avec un temps de chargement initial rapide	✔️Pris en charge	❌Non pris en charge	❌Non pris en charge
Vitesse d’exécution quasi native	✔️Pris en charge	✔️Pris en charge‡	✔️Pris en charge
Code d’application sécurisé et privé sur le serveur	✔️Pris en charge	❌Non pris en charge†	❌Non pris en charge†
Exécuter des applications hors connexion une fois téléchargées	❌Non pris en charge	✔️Pris en charge	✔️Pris en charge
Hébergement de site statique	❌Non pris en charge	✔️Pris en charge	❌Non pris en charge
Décharge le traitement vers les clients	❌Non pris en charge	✔️Pris en charge	✔️Pris en charge
Accès complet aux fonctionnalités du client natif	❌Non pris en charge	❌Non pris en charge	✔️Pris en charge
Déploiement basé sur le web	✔️Pris en charge	✔️Pris en charge	❌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é API .NET complète, tandis que les composants rendus pour Blazor WebAssembly sont limités à un sous-ensemble d’API .NET. Quand la spécification d’une application nécessite une ou plusieurs API .NET qui ne sont pas disponibles pour les composants WebAssembly-rendered, choisissez alors de rendre des composants pour Blazor Server ou utilisez Blazor Hybrid.

Accès direct aux ressources serveur et réseau

Les composants rendus pour le modèle d’hébergement Blazor Server ont un accès direct aux ressources serveur et réseau où l’application s’exécute. Les composants hébergés en utilisant Blazor WebAssembly ou Blazor Hybrid s’exécutant sur un client, ils n’ont pas d’accès direct aux ressources serveur et réseau. Les composants peuvent accéder indirectement aux ressources serveur et réseau via des API basées sur un serveur protégé. 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 de devoir exposer des API depuis l’environnement serveur.

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

Rendre des composants depuis un serveur réduit la taille de la charge utile de l’application et améliore les temps de chargement initiaux. Quand vous souhaitez que le délai de chargement initial soit rapide, utilisez le modèle d’hébergement Blazor Server, ou optez pour le rendu côté serveur statique.

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 pour le modèle d’hébergement Blazor WebAssembly, y compris les applications web progressives (Progressive Web Apps/PWA) et les applications autonomes Blazor WebAssembly s’exécutent à l’aide du runtime .NET pour WebAssembly, ce qui est plus lent que de s’exécuter directement sur la plateforme. Envisagez d’utiliser la compilation anticipée (Ahead of Time/AOT) pour améliorer les performances du runtime lors de l’utilisation de Blazor WebAssembly.

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

La gestion sécurisée et privée du code d’application sur le serveur est une fonctionnalité intégrée des composants rendus pour le modèle d’hébergement Blazor Server. Les composants rendus à l’aide des modèles d’hébergement Blazor WebAssembly ou Blazor Hybrid peuvent utiliser des API basées sur serveur pour accéder aux fonctionnalités qui doivent être conservées 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 des API basées sur serveur ne sont pas souhaitables pour maintenir le code d’application sécurisé et privé, adoptez 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’applications web progressives (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 pour le modèle d’hébergement Blazor Server ne parviennent pas à s’exécuter lorsque la connexion au serveur est perdue. Si une application doit s'exécuter hors connexion, Blazor WebAssembly et Blazor Hybrid autonomes sont les plus adaptées.

Hébergement de site statique

L’hébergement de site statique est possible avec les applications Blazor WebAssembly autonomes, car elles sont téléchargées vers les clients sous la forme d’un ensemble de fichiers statiques. Les applications Blazor WebAssembly autonomes n’ont pas besoin de serveur pour exécuter du code côté serveur afin de télécharger et d’exécuter, et peuvent être remises via un réseau de distribution de contenu (Content Delivery Network/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, sélectionnez 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 applications web Blazor sont mises à jour lors de l’actualisation suivante de l’application depuis 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 sur Blazor Server ou Blazor WebAssembly au moment de la compilation, ou dynamiquement au moment de l’exécution, vous définissez son mode de rendu. Les modes de rendu sont entièrement expliqués et illustrés dans l’article Modes de rendu ASP.NET CoreBlazor. Nous vous déconseillons de passer directement de cet article à l’article Modes de rendu sans lire le contenu des articles intermédiaires. Par exemple, les modes de rendu sont plus facilement compris en examinant les exemples de composant Razor, mais la structure et la fonction de base des composants Razor ne sont pas couvertes tant que l’article Principes fondamentaux Blazor ASP.NET Core n’est pas atteint. Il est également utile d’en savoir plus sur les modèles de projet et les outils de Blazor avant d’utiliser les exemples de composant dans l’article Modes de rendu.