Blazor-Hostingmodelle in ASP.NET Core

In diesem Artikel werden die verschiedenen Blazor-Hostingmodelle erklärt, und es wird erläutert, wie Sie das richtige Modell auswählen.

Blazor ist ein Webframework zur Erstellung von Komponenten von Webbenutzeroberflächen (Razor-Komponenten), die auf verschiedene Arten gehostet werden können. Razor-Komponenten können serverseitig in ASP.NET Core (Blazor Server) und clientseitig im Browser in einer WebAssembly-basierten .NET-Runtime (Blazor WebAssembly, Blazor WASM) ausgeführt werden. Sie können auch Razor-Komponenten in nativen mobilen und Desktop-Apps hosten, die in einem eingebetteten Web View-Steuerelement gerendert werden (Blazor Hybrid). Unabhängig vom Hostingmodell ist die Art und Weise, wie Sie Razor-Komponenten erstellen, identisch. Die gleichen Razor-Komponenten können mit jedem der Hostingmodelle unverändert verwendet werden.

Blazor Server

Mit dem Blazor Server-Hostingmodell wird die App über eine ASP.NET Core-App auf dem Server ausgeführt. Benutzeroberflächenupdates, Ereignisbehandlung und JavaScript-Aufrufe werden über eine SignalR-Verbindung verarbeitet. Der Zustand auf dem Server, der jedem verbundenen Client zugeordnet ist, wird als Leitung bezeichnet. Eine Leitung kann vorübergehende Netzwerkunterbrechungen tolerieren sowie Versuche des Clients, die Verbindung mit dem Server bei einer Unterbrechung wiederherzustellen.

Bei herkömmlichen, auf dem Server gerenderten Apps führt das gleichzeitige Öffnen einer App in mehreren Browserfenstern (Registerkarten oder iframes) in der Regel nicht zu zusätzlichen Ressourcenanforderungen auf dem Server. In einer Blazor Server-App erfordert jedes Browserfenster eine separate Leitung und separate Instanzen des vom Server verwalteten Komponentenzustands. In Blazor gilt das Schließen einer Browserregisterkarte oder das Navigieren zu einer externen URL als ordnungsgemäße Beendigung. Bei einer ordnungsgemäßen Beendigung werden die Verbindung und die zugehörigen Ressourcen sofort freigegeben. Die Verbindung zu einem Client kann auch nicht ordnungsgemäß getrennt werden, beispielsweise aufgrund einer Netzwerkunterbrechung. Blazor Server speichert getrennte Verbindungen für die Dauer eines konfigurierbaren Intervalls, damit der Client noch mal eine Verbindung herstellen kann.

The browser interacts with the app (hosted inside of an ASP.NET Core app) on the server over a SignalR connection.

Auf dem Client stellt das Blazor-Skript (blazor.server.js) die SignalR-Verbindung mit dem Server her. Das Skript wird in einer eingebetteten Ressource im freigegebenen ASP.NET Core-Framework für die clientseitige App bereitgestellt. Die clientseitige App ist ggf. für das Beibehalten und Wiederherstellen des App-Zustands verantwortlich.

Das Blazor Server-Hostingmodell besitzt folgende Vorteile:

  • Die Downloadgröße ist im Vergleich zu einer Blazor WebAssembly-App deutlich kleiner und die Ladezeit der App wesentlich kürzer.
  • Die Serverfunktionen, einschließlich .NET Core-APIs, werden von der App in vollem Umfang genutzt.
  • Da auf dem Server .NET Core zum Ausführen der App verwendet wird, funktionieren vorhandene .NET-Tools, wie das Debuggen, erwartungsgemäß.
  • Thin Clients werden unterstützt. So funktionieren Blazor Server-Apps auch mit Browsern, die WebAssembly nicht unterstützen, sowie auf Geräten mit eingeschränkten Ressourcen.
  • Die .NET-/C#-Codebasis der App, einschließlich des Komponentencodes, werden nicht für Clients bereitgestellt.

Für das Blazor Server-Hostingmodell gelten die folgenden Einschränkungen:

  • In der Regel ist mit einer höheren Latenzzeit zu rechnen. Bei jeder Benutzerinteraktion fällt ein Netzwerkhop an.
  • Es gibt keine Offlineunterstützung. Bei einer Unterbrechung der Clientverbindung funktioniert die App nicht mehr.
  • Für die Skalierung von Apps mit vielen Benutzern werden zur Verarbeitung mehrerer Clientverbindungen und -zustände Serverressourcen benötigt.
  • Zum Bereitstellen der App ist ein ASP.NET Core-Server erforderlich. Eine serverlose Bereitstellung ist nicht möglich, z. B. das Bereitstellen der App aus einem Content Delivery Network (CDN).

Sie sollten Azure SignalR Service für Blazor Server-Apps verwenden. Der Dienst ermöglicht das Hochskalieren einer Blazor Server-App auf eine große Anzahl gleichzeitiger SignalR-Verbindungen.

Blazor WebAssembly

Blazor WebAssembly-Apps (WASM) werden auf Clientseite im Browser in einer auf WebAssembly basierenden .NET-Runtime ausgeführt. Die Blazor-App, die jeweiligen Abhängigkeiten und die .NET-Runtime werden im Browser heruntergeladen. Die App wird direkt im UI-Thread des Browsers ausgeführt. Die Aktualisierung der Benutzeroberfläche und die Ereignisbehandlung erfolgen im selben Prozess. Die Ressourcen der App werden als statische Dateien auf einem Webserver oder für einen Dienst bereitgestellt, die geeignet sind, statische Inhalte für Clients bereitzustellen.

Blazor WebAssembly: The Blazor app runs on a UI thread inside the browser.

Wenn die Blazor WebAssembly-App für die Bereitstellung ohne ASP.NET Core-App im Back-End für die Bereitstellung der zugehörigen Dateien erstellt wird, wird die App als eigenständigeBlazor WebAssembly-App bezeichnet. Wenn die App für die Bereitstellung mit einer Back-End-App zum Bereitstellen der zugehörigen Dateien erstellt wird, wird die App als gehosteteBlazor WebAssembly-App bezeichnet.

Mit einer gehosteten Blazor WebAssembly-App erhalten Sie eine vollständige .NET-Benutzeroberfläche für die Webentwicklung, einschließlich der Möglichkeit zur Freigabe von Code zwischen Client- und Server-Apps, Unterstützung für Vorabrendern sowie der Integration in MVC und Razor Pages. Eine gehostete Client-App kann mit der zugehörigen Server-App im Back-End über das Netzwerk mithilfe einer Vielzahl von Messagingframeworks und Protokollen interagieren, z. B. Web-API, gRPC-web und SignalR (Verwenden von ASP.NET Core SignalR mit Blazor).

Das blazor.webassembly.js-Skript wird vom Framework und von den Handles bereitgestellt:

  • Herunterladen der .NET-Runtime, der App und der App-Abhängigkeiten
  • Initialisieren der Runtime, mit der die App ausgeführt wird

Das Blazor WebAssembly-Hostingmodell (WASM) bietet mehrere Vorteile:

  • Nach dem Herunterladen vom Server besteht keine serverseitige .NET-Abhängigkeit, wodurch die App auch bei einem offline geschalteten Server funktionsfähig bleibt.
  • Die Ressourcen und Funktionen des Clients werden voll genutzt.
  • Die Arbeit wird vom Server auf den Client verlagert.
  • Es ist kein ASP.NET Core-Webserver zum Hosten der App erforderlich. Eine serverlose Bereitstellung ist möglich, z. B. das Bereitstellen der App aus einem Content Delivery Network (CDN).

Für das Blazor WebAssembly-Hostingmodell gelten die folgenden Einschränkungen:

  • Die App ist auf die Funktionen des Browsers beschränkt.
  • Es ist geeignete Clienthardware und -software erforderlich (z. B. WebAssembly-Unterstützung).
  • Die Downloadmenge ist größer und die Ladezeit der Apps länger.

Blazor WebAssembly unterstützt die AOT-Kompilierung, mit der Sie Ihren .NET-Code direkt in WebAssembly kompilieren können. Die AOT-Kompilierung verbessert die Runtimeleistung, allerdings nimmt die Größe der App zu. Weitere Informationen finden Sie unter Hosten und Bereitstellen von Blazor WebAssembly in ASP.NET Core.

Mit den für die AOT-Kompilierung verwendeten .NET WebAssembly-Buildtools können Sie auch eine Neuverknüpfung mit der .NET WebAssembly-Runtime herstellen, um nicht verwendeten Runtimecode zu kürzen.

Blazor WebAssembly unterstützt das Kürzen von nicht verwendetem Code aus .NET Core-Frameworkbibliotheken. Weitere Informationen finden Sie unter Blazor in ASP.NET Core: Globalisierung und Lokalisierung. Durch den .NET-Compiler wird eine Blazor WebAssembly-App vorkomprimiert, um die Nutzdaten der App zu reduzieren.

Blazor WebAssembly-Apps können native Abhängigkeiten verwenden, die für die Ausführung in WebAssembly erstellt wurden.

Blazor Hybrid

Blazor kann auch verwendet werden, um native Client-Apps mithilfe eines hybriden Ansatzes zu erstellen. Hybrid-Apps sind native Apps, die Webtechnologien für ihre Funktionalität nutzen. In einer Blazor Hybrid-App werden Razor-Komponenten zusammen mit anderem .NET-Code direkt in der nativen App (nicht in WebAssembly) ausgeführt und rendern die Webbenutzeroberfläche basierend auf HTML und CSS über einen lokalen Interopkanal an ein eingebettetes Web View-Steuerelement.

Hybrid apps with .NET and Blazor render UI in a Web View control, where the HTML Document Object Model (DOM) interacts with Blazor and .NET of the native desktop or mobile app.

Blazor Hybrid-Apps können mit verschiedenen nativen .NET-App-Frameworks erstellt werden, darunter .NET MAUI, WPF und Windows Forms. Blazor bietet BlazorWebView-Steuerelemente zum Hinzufügen von Razor-Komponenten zu Apps, die mit diesen Frameworks erstellt wurden. Die Verwendung von Blazor mit .NET MAUI bietet eine bequeme Möglichkeit, plattformübergreifende Blazor Hybrid-Apps für Mobilgeräte und Desktops zu erstellen, während die Blazor-Integration mit WPF und Windows Forms eine hervorragende Möglichkeit ist, vorhandene Apps zu modernisieren.

Da es sich bei Blazor Hybrid Apps um native Apps handelt, können sie Funktionen unterstützen, die auf der Webplattform allein nicht verfügbar sind. Blazor Hybrid-Apps haben über die normalen .NET-APIs Voolzugriff auf die Funktionen der nativen Plattform. Blazor Hybrid-Apps können auch Komponenten mit bestehenden Blazor Server- oder Blazor WebAssembly-Apps gemeinsam nutzen und wiederverwenden. Blazor Hybrid-Apps kombinieren die Vorteile des Webs, nativer Apps und der .NET-Plattform.

Das Blazor Hybrid-Hostingmodell besitzt folgende Vorteile:

  • Wiederverwendung vorhandener Komponenten, die auf Mobilgeräten, Desktops und im Web gemeinsam genutzt werden können.
  • Nutzen von Fertigkeiten, Erfahrungen und Ressourcen für die Webentwicklung.
  • Apps haben Vollzugriff auf die nativen Funktionen des Geräts.

Für das Blazor Hybrid-Hostingmodell gelten die folgenden Einschränkungen:

  • Für jede Zielplattform müssen separate native Client-Apps erstellt, bereitgestellt und gepflegt werden.
  • Bei nativen Client-Apps dauert es in der Regel länger, sie zu finden, herunterzuladen und zu installieren als beim Zugriff auf eine Web-App in einem Browser.

Weitere Informationen finden Sie unter ASP.NET Core Blazor Hybrid.

Weitere Informationen zu nativen Microsoft-Clientframeworks finden Sie in den folgenden Ressourcen:

Welches Blazor-Hostingmodell sollte ich wählen?

Wählen Sie das Blazor-Hostingmodell basierend auf den Featureanforderungen der App aus. Die folgende Tabelle enthält die wichtigsten Aspekte bei der Auswahl des Hostingmodells.

Funktion Blazor Server Blazor WebAssembly (WASM) Blazor Hybrid
Vollständige Kompatibilität mit der .NET-API ✔️ ✔️
Direkter Zugriff auf Server- und Netzwerkressourcen ✔️ ❌† ❌†
Kleine Nutzlastgröße mit kurzer anfänglicher Ladedauer ✔️
App-Code ist auf dem Server sicher und privat ✔️ ❌† ❌†
Apps können nach dem Herunterladen offline ausgeführt werden ✔️ ✔️
Hosten statischer Websites ✔️
Verarbeiten der Auslagerung auf Clients ✔️ ✔️
Vollzugriff auf native Clientfunktionen ✔️

† Blazor WebAssembly- und Blazor Hybrid-Apps können serverbasierte APIs für den Zugriff auf Server- und Netzwerkressourcen sowie für den Zugriff auf privaten und geschützten App-Code verwenden.

Nachdem Sie das Hostingmodell der App gewählt haben, können Sie eine Blazor Server- oder Blazor WebAssembly-App aus einer Blazor-Projektvorlage generieren. Weitere Informationen finden Sie unter Tools für ASP.NET Core Blazor.

Um eine Blazor Hybrid-App zu erstellen, lesen Sie die Artikel unter Blazor Hybrid-Tutorials für ASP.NET Core.

Vollständige Kompatibilität mit der .NET-API

Blazor Server- und Blazor Hybrid-Apps sind vollständig mit der .NET-API kompatibel, während Blazor WebAssembly-Apps auf eine Teilmenge der .NET-APIs beschränkt sind. Wenn die Spezifikation einer App eine oder mehrere .NET-APIs erfordert, die für Blazor WebAssembly-Apps nicht verfügbar sind, wählen Sie Blazor Server oder Blazor Hybrid aus.

Direkter Zugriff auf Server- und Netzwerkressourcen

Blazor Server-Apps haben direkten Zugriff auf die Server- und Netzwerkressourcen, auf denen die App ausgeführt wird. Da Blazor WebAssembly- und Blazor Hybrid-Apps auf einem Client ausgeführt werden, haben sie keinen direkten Zugriff auf Server- und Netzwerkressourcen. Blazor WebAssembly- und Blazor Hybrid-Apps können indirekt über geschützte serverbasierte APIs auf Server- und Netzwerkressourcen zugreifen. Serverbasierte APIs sind möglicherweise über Bibliotheken, Pakete und Dienste von Drittanbietern verfügbar. Berücksichtigen Sie die folgenden Aspekte:

  • Die Implementierung und Wartung von Bibliotheken, Paketen und Diensten von Drittanbietern kann kostspielig sein und Sicherheitsrisiken mit sich bringen. Zudem wird nicht immer ausreichend Support angeboten.
  • Wenn eine oder mehrere serverbasierte APIs intern von Ihrer Organisation entwickelt werden, ist zusätzlicher Aufwand erforderlich, um sie zu erstellen und zu verwalten.

Um serverbasierte APIs für Blazor WebAssembly- oder Blazor Hybrid-Apps zu vermeiden, verwenden Sie Blazor Server, um den direkten Zugriff auf Server- und Netzwerkressourcen zu ermöglichen.

Kleine Nutzlastgröße mit kurzer anfänglicher Ladedauer

Blazor Server-Apps weisen relativ wenige Nutzdaten mit schnelleren anfänglichen Ladezeiten auf. Verwenden Sie Blazor Server, wenn Sie schnelle anfängliche Ladezeiten erzielen möchten.

App-Code ist auf dem Server sicher und privat

Die sichere und private Verwaltung von App-Code auf dem Server ist ein integriertes Feature von Blazor Server. Blazor WebAssembly- und Blazor Hybrid-Apps können mithilfe serverseitig gehosteter APIs auf Funktionen zugreifen, die privat und geschützt bleiben sollen. Es gelten die im Abschnitt Direkter Zugriff auf Server- und Netzwerkressourcen beschriebenen Aspekte für die Entwicklung und Verwaltung serverbasierter APIs. Wenn die Entwicklung und Wartung serverbasierter APIs für die Verwaltung von sicherem und privatem App-Code nicht wünschenswert ist, übernehmen Sie das Blazor Server-Hostingmodell.

Apps können nach dem Herunterladen offline ausgeführt werden

Blazor WebAssembly- und Blazor Hybrid-Apps können offline ausgeführt werden. Das ist insbesondere dann nützlich, wenn Clients keine Verbindung mit dem Internet herstellen können. Blazor Server-Apps werden nicht ausgeführt, wenn die Verbindung mit dem Server unterbrochen wird. Wenn eine App offline ausgeführt werden muss, sind Blazor WebAssembly und Blazor Hybrid die beste Wahl.

Hosten statischer Websites

Das Hosten statischer Websites ist mit Blazor WebAssembly-Apps möglich, da sie als statische Dateien auf Clients heruntergeladen werden. Blazor WebAssembly-Apps benötigen keinen Server für die Ausführung von serverseitigem Code, um Inhalte herunterladen und ausführen zu können. Blazor WebAssembly-Apps können über ein Content Delivery Network (CDN) wie Azure CDN bereitgestellt werden. Obwohl Blazor Hybrid-Apps in ein oder mehrere eigenständige Bereitstellungsressourcen kompiliert werden, werden die Ressourcen in der Regel über den App Store eines Drittanbieters für Clients bereitgestellt. Verwenden Sie Blazor WebAssembly, wenn statisches Hosting für die App erforderlich ist.

Verarbeiten der Auslagerung auf Clients

Blazor WebAssembly- und Blazor Hybrid-Apps werden auf Clients ausgeführt und lagern daher die Verarbeitung an Clients aus. Blazor Server-Apps werden auf einem Server ausgeführt, sodass der Bedarf an Serverressourcen in der Regel mit der Benutzeranzahl und dem Verarbeitungsvolumen pro Benutzer steigt. Wenn es möglich ist, die meisten oder alle Verarbeitungsvorgänge einer App an Clients auszulagern und die App große Datenmengen verarbeitet, ist Blazor WebAssembly oder Blazor Hybrid die beste Wahl.

Vollzugriff auf native Clientfunktionen

Blazor Hybrid Apps haben über native .NET-App-Frameworks Vollzugriff auf native Client-API-Funktionen. In Blazor Hybrid-Apps werden Razor-Komponenten direkt in der nativen App und nicht in WebAssembly ausgeführt. Wenn alle Clientfunktionen erforderlich sind, ist Blazor Hybrid die beste Wahl.

Zusätzliche Ressourcen

Blazor ist ein Webframework zur Erstellung von Komponenten von Webbenutzeroberflächen (Razor-Komponenten), die auf verschiedene Arten gehostet werden können. Razor-Komponenten können serverseitig in ASP.NET Core (Blazor Server) und clientseitig im Browser in einer WebAssembly-basierten .NET-Runtime (Blazor WebAssembly, Blazor WASM) ausgeführt werden. Unabhängig vom Hostingmodell ist die Art und Weise, wie Sie Razor-Komponenten erstellen, identisch. Die gleichen Razor-Komponenten können mit jedem der Hostingmodelle unverändert verwendet werden.

Blazor Server

Mit dem Blazor Server-Hostingmodell wird die App über eine ASP.NET Core-App auf dem Server ausgeführt. Benutzeroberflächenupdates, Ereignisbehandlung und JavaScript-Aufrufe werden über eine SignalR-Verbindung verarbeitet. Der Zustand auf dem Server, der jedem verbundenen Client zugeordnet ist, wird als Leitung bezeichnet. Eine Leitung kann vorübergehende Netzwerkunterbrechungen tolerieren sowie Versuche des Clients, die Verbindung mit dem Server bei einer Unterbrechung wiederherzustellen.

Bei herkömmlichen, auf dem Server gerenderten Apps führt das gleichzeitige Öffnen einer App in mehreren Browserfenstern (Registerkarten oder iframes) in der Regel nicht zu zusätzlichen Ressourcenanforderungen auf dem Server. In einer Blazor Server-App erfordert jedes Browserfenster eine separate Leitung und separate Instanzen des vom Server verwalteten Komponentenzustands. In Blazor gilt das Schließen einer Browserregisterkarte oder das Navigieren zu einer externen URL als ordnungsgemäße Beendigung. Bei einer ordnungsgemäßen Beendigung werden die Verbindung und die zugehörigen Ressourcen sofort freigegeben. Die Verbindung zu einem Client kann auch nicht ordnungsgemäß getrennt werden, beispielsweise aufgrund einer Netzwerkunterbrechung. Blazor Server speichert getrennte Verbindungen für die Dauer eines konfigurierbaren Intervalls, damit der Client noch mal eine Verbindung herstellen kann.

The browser interacts with the app (hosted inside of an ASP.NET Core app) on the server over a SignalR connection.

Auf dem Client stellt das Blazor-Skript (blazor.server.js) die SignalR-Verbindung mit dem Server her. Das Skript wird in einer eingebetteten Ressource im freigegebenen ASP.NET Core-Framework für die clientseitige App bereitgestellt. Die clientseitige App ist ggf. für das Beibehalten und Wiederherstellen des App-Zustands verantwortlich.

Das Blazor Server-Hostingmodell besitzt folgende Vorteile:

  • Die Downloadgröße ist im Vergleich zu einer Blazor WebAssembly-App deutlich kleiner und die Ladezeit der App wesentlich kürzer.
  • Die Serverfunktionen, einschließlich .NET Core-APIs, werden von der App in vollem Umfang genutzt.
  • Da auf dem Server .NET Core zum Ausführen der App verwendet wird, funktionieren vorhandene .NET-Tools, wie das Debuggen, erwartungsgemäß.
  • Thin Clients werden unterstützt. So funktionieren Blazor Server-Apps auch mit Browsern, die WebAssembly nicht unterstützen, sowie auf Geräten mit eingeschränkten Ressourcen.
  • Die .NET-/C#-Codebasis der App, einschließlich des Komponentencodes, werden nicht für Clients bereitgestellt.

Für das Blazor Server-Hostingmodell gelten die folgenden Einschränkungen:

  • In der Regel ist mit einer höheren Latenzzeit zu rechnen. Bei jeder Benutzerinteraktion fällt ein Netzwerkhop an.
  • Es gibt keine Offlineunterstützung. Bei einer Unterbrechung der Clientverbindung funktioniert die App nicht mehr.
  • Für die Skalierung von Apps mit vielen Benutzern werden zur Verarbeitung mehrerer Clientverbindungen und -zustände Serverressourcen benötigt.
  • Zum Bereitstellen der App ist ein ASP.NET Core-Server erforderlich. Eine serverlose Bereitstellung ist nicht möglich, z. B. das Bereitstellen der App aus einem Content Delivery Network (CDN).

Sie sollten Azure SignalR Service für Blazor Server-Apps verwenden. Der Dienst ermöglicht das Hochskalieren einer Blazor Server-App auf eine große Anzahl gleichzeitiger SignalR-Verbindungen.

Blazor WebAssembly

Blazor WebAssembly-Apps (WASM) werden auf Clientseite im Browser in einer auf WebAssembly basierenden .NET-Runtime ausgeführt. Die Blazor-App, die jeweiligen Abhängigkeiten und die .NET-Runtime werden im Browser heruntergeladen. Die App wird direkt im UI-Thread des Browsers ausgeführt. Die Aktualisierung der Benutzeroberfläche und die Ereignisbehandlung erfolgen im selben Prozess. Die Ressourcen der App werden als statische Dateien auf einem Webserver oder für einen Dienst bereitgestellt, die geeignet sind, statische Inhalte für Clients bereitzustellen.

Blazor WebAssembly: The Blazor app runs on a UI thread inside the browser.

Wenn die Blazor WebAssembly-App für die Bereitstellung ohne ASP.NET Core-App im Back-End für die Bereitstellung der zugehörigen Dateien erstellt wird, wird die App als eigenständigeBlazor WebAssembly-App bezeichnet. Wenn die App für die Bereitstellung mit einer Back-End-App zum Bereitstellen der zugehörigen Dateien erstellt wird, wird die App als gehosteteBlazor WebAssembly-App bezeichnet.

Mit einer gehosteten Blazor WebAssembly-App erhalten Sie eine vollständige .NET-Benutzeroberfläche für die Webentwicklung, einschließlich der Möglichkeit zur Freigabe von Code zwischen Client- und Server-Apps, Unterstützung für Vorabrendern sowie der Integration in MVC und Razor Pages. Eine gehostete Client-App kann mit der zugehörigen Server-App im Back-End über das Netzwerk mithilfe einer Vielzahl von Messagingframeworks und Protokollen interagieren, z. B. Web-API, gRPC-web und SignalR (Verwenden von ASP.NET Core SignalR mit Blazor).

Das blazor.webassembly.js-Skript wird vom Framework und von den Handles bereitgestellt:

  • Herunterladen der .NET-Runtime, der App und der App-Abhängigkeiten
  • Initialisieren der Runtime, mit der die App ausgeführt wird

Das Blazor WebAssembly-Hostingmodell (WASM) bietet mehrere Vorteile:

  • Nach dem Herunterladen vom Server besteht keine serverseitige .NET-Abhängigkeit, wodurch die App auch bei einem offline geschalteten Server funktionsfähig bleibt.
  • Die Ressourcen und Funktionen des Clients werden voll genutzt.
  • Die Arbeit wird vom Server auf den Client verlagert.
  • Es ist kein ASP.NET Core-Webserver zum Hosten der App erforderlich. Eine serverlose Bereitstellung ist möglich, z. B. das Bereitstellen der App aus einem Content Delivery Network (CDN).

Für das Blazor WebAssembly-Hostingmodell gelten die folgenden Einschränkungen:

  • Die App ist auf die Funktionen des Browsers beschränkt.
  • Es ist geeignete Clienthardware und -software erforderlich (z. B. WebAssembly-Unterstützung).
  • Die Downloadmenge ist größer und die Ladezeit der Apps länger.

Blazor WebAssembly unterstützt das Kürzen von nicht verwendetem Code aus .NET Core-Frameworkbibliotheken. Weitere Informationen finden Sie unter Blazor in ASP.NET Core: Globalisierung und Lokalisierung.

Welches Blazor-Hostingmodell sollte ich wählen?

Wählen Sie das Blazor-Hostingmodell basierend auf den Featureanforderungen der App aus. Die folgende Tabelle enthält die wichtigsten Aspekte bei der Auswahl des Hostingmodells.

Funktion Blazor Server Blazor WebAssembly (WASM)
Vollständige Kompatibilität mit der .NET-API ✔️
Direkter Zugriff auf Server- und Netzwerkressourcen ✔️ ❌†
Kleine Nutzlastgröße mit kurzer anfänglicher Ladedauer ✔️
App-Code ist auf dem Server sicher und privat ✔️ ❌†
Apps können nach dem Herunterladen offline ausgeführt werden ✔️
Hosten statischer Websites ✔️
Verarbeiten der Auslagerung auf Clients ✔️

† Blazor WebAssembly-Apps können serverbasierte APIs für den Zugriff auf Server- und Netzwerkressourcen sowie für den Zugriff auf privaten und geschützten App-Code verwenden.

Nachdem Sie das Hostingmodell der App gewählt haben, können Sie eine Blazor Server- oder Blazor WebAssembly-App aus einer Blazor-Projektvorlage generieren. Weitere Informationen finden Sie unter Tools für ASP.NET Core Blazor.

Vollständige Kompatibilität mit der .NET-API

Blazor Server-Apps sind vollständig mit der .NET-API kompatibel, während Blazor WebAssembly-Apps auf eine Teilmenge der .NET-APIs beschränkt sind. Wenn die Spezifikation einer App eine oder mehrere .NET-APIs erfordert, die für Blazor WebAssembly-Apps nicht verfügbar sind, wählen Sie Blazor Server aus.

Direkter Zugriff auf Server- und Netzwerkressourcen

Blazor Server-Apps haben direkten Zugriff auf die Server- und Netzwerkressourcen, auf denen die App ausgeführt wird. Da Blazor WebAssembly-Apps auf einem Client ausgeführt werden, haben sie keinen direkten Zugriff auf Server- und Netzwerkressourcen. Blazor WebAssembly-Apps können indirekt über geschützte serverbasierte APIs auf Server- und Netzwerkressourcen zugreifen. Serverbasierte APIs sind möglicherweise über Bibliotheken, Pakete und Dienste von Drittanbietern verfügbar. Berücksichtigen Sie die folgenden Aspekte:

  • Die Implementierung und Wartung von Bibliotheken, Paketen und Diensten von Drittanbietern kann kostspielig sein und Sicherheitsrisiken mit sich bringen. Zudem wird nicht immer ausreichend Support angeboten.
  • Wenn eine oder mehrere serverbasierte APIs intern von Ihrer Organisation entwickelt werden, ist zusätzlicher Aufwand erforderlich, um sie zu erstellen und zu verwalten.

Um serverbasierte APIs für Blazor WebAssembly-Apps zu vermeiden, verwenden Sie Blazor Server, um den direkten Zugriff auf Server- und Netzwerkressourcen zu ermöglichen.

Kleine Nutzlastgröße mit kurzer anfänglicher Ladedauer

Blazor Server-Apps weisen relativ wenige Nutzdaten mit schnelleren anfänglichen Ladezeiten auf. Verwenden Sie Blazor Server, wenn Sie schnelle anfängliche Ladezeiten erzielen möchten.

App-Code ist auf dem Server sicher und privat

Die sichere und private Verwaltung von App-Code auf dem Server ist ein integriertes Feature von Blazor Server. Blazor WebAssembly-Apps können mithilfe serverseitig gehosteter APIs auf Funktionen zugreifen, die privat und geschützt bleiben sollen. Es gelten die im Abschnitt Direkter Zugriff auf Server- und Netzwerkressourcen beschriebenen Aspekte für die Entwicklung und Verwaltung serverbasierter APIs. Wenn die Entwicklung und Wartung serverbasierter APIs für die Verwaltung von sicherem und privatem App-Code nicht wünschenswert ist, übernehmen Sie das Blazor Server-Hostingmodell.

Apps können nach dem Herunterladen offline ausgeführt werden

Blazor WebAssembly-Apps können offline ausgeführt werden. Das ist insbesondere dann nützlich, wenn Clients keine Verbindung mit dem Internet herstellen können. Blazor Server-Apps werden nicht ausgeführt, wenn die Verbindung mit dem Server unterbrochen wird. Wenn eine App offline ausgeführt werden muss, ist Blazor WebAssembly die beste Wahl.

Hosten statischer Websites

Das Hosten statischer Websites ist mit Blazor WebAssembly-Apps möglich, da sie als statische Dateien auf Clients heruntergeladen werden. Blazor WebAssembly-Apps benötigen keinen Server für die Ausführung von serverseitigem Code, um Inhalte herunterladen und ausführen zu können. Blazor WebAssembly-Apps können über ein Content Delivery Network (CDN) wie Azure CDN bereitgestellt werden. Verwenden Sie Blazor WebAssembly, wenn statisches Hosting für die App erforderlich ist.

Verarbeiten der Auslagerung auf Clients

Blazor WebAssembly-Apps werden auf Clients ausgeführt und lagern daher die Verarbeitung an Clients aus. Blazor Server-Apps werden auf einem Server ausgeführt, sodass der Bedarf an Serverressourcen in der Regel mit der Benutzeranzahl und dem Verarbeitungsvolumen pro Benutzer steigt. Wenn es möglich ist, die meisten oder alle Verarbeitungsvorgänge einer App an Clients auszulagern und die App große Datenmengen verarbeitet, ist Blazor WebAssembly die beste Wahl.

Zusätzliche Ressourcen