Blazor-Hostingmodelle in ASP.NET Core

Das Webframework Blazor kann auf Clientseite im Browser in einer auf WebAssembly basierenden .NET-Runtime ( Blazor WebAssembly ) oder auf Serverseite in ASP.NET Core ( Blazor Server ) ausgeführt werden. Die App und die Komponentenmodelle sind für alle Hostingmodelle identisch.

Blazor WebAssembly

Blazor WebAssembly-Apps 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: Die Blazor-App wird in einem Benutzeroberflächenthread im Browser ausgeführt.

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ändige Blazor 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 gehostete Blazor WebAssembly-App bezeichnet. Eine gehostete Blazor WebAssembly Client -App interagiert in der Regel mit Web-API-Aufrufen oder SignalR (Verwenden von ASP.NET Core SignalR mit Blazor)über das Netzwerk mit der Back-End- Server -App.

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 besitzt folgende Vorteile:

  • Es besteht keine serverseitige .NET-Abhängigkeit. Nach dem Herunterladen auf den Client ist die App voll funktionsfähig.
  • 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.
  • Die Unterstützung für die .NET-Runtime und -Tools ist weniger ausgereift. Bei der Unterstützung und dem Debuggen in .NET Standard existieren beispielsweise Einschränkungen.

Informationen zum Erstellen einer Blazor WebAssembly-App finden Sie unter Tools für ASP.NET-Core Blazor.

Das Blazor-Modell für gehostete Apps unterstützt Docker-Container. Klicken Sie für Docker-Unterstützung in Visual Studio mit der rechten Maustaste auf das Server -Projekt einer gehosteten Blazor WebAssembly-Projektmappe, und wählen Sie Hinzufügen > Docker-Support.

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 Browser interagiert mit der (in einer ASP.NET Core-App gehosteten) App über eine SignalR-Verbindung auf dem Server.

Die ASP.NET Core-App verweist auf die Startup-Klasse der App, um folgende Aktionen durchzuführen:

  • Hinzufügen serverseitiger Dienste
  • Hinzufügen der App zur Pipeline für die Anforderungsverarbeitung

Auf dem Client stellt das blazor.server.js-Skript 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 werden in vollem Umfang genutzt, einschließlich aller mit .NET Core kompatiblen APIs.
  • 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.

Wichtig

Als Reaktion auf die erste Clientanforderung führt die Blazor Server-App ein Prerendering aus, das den Zustand der Benutzeroberfläche auf dem Server festlegt. Versucht der Client, eine SignalR-Verbindung zu erstellen, muss er mit demselben Server erneut eine Verbindung herstellen. Blazor Server-Apps mit mehr als einem Back-End-Server sollten für SignalR-Verbindungen persistente Sitzungen implementieren. Weitere Informationen finden Sie im Abschnitt Verbindung mit dem Server.

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.
  • Die Skalierbarkeit ist bei Apps mit vielen Benutzern schwierig. Der Server muss eine Vielzahl von Clientverbindungen verwalten und Clientzustände verarbeiten.
  • 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).

Informationen zum Erstellen einer Blazor Server-App finden Sie unter Tools für ASP.NET-Core Blazor.

Das Blazor Server-App-Modell unterstützt Docker-Container. Klicken Sie für Docker-Unterstützung in Visual Studio mit der rechten Maustaste auf das Projekt in Visual Studio, und wählen Sie Hinzufügen > Docker-Unterstützung aus.

Vergleich mit einer auf dem Server gerenderten Benutzeroberfläche

Die Unterschiede zwischen Blazor Server-Apps und traditionellen Modellen beim Rendern von Benutzeroberflächen in ASP.NET Core-Apps mit Razor-Ansichten oder Razor Pages zu kennen ist entscheidend. Bei beiden Modellen wird zum Beschreiben von HTML-Inhalt die Razor-Syntax verwendet. Deutliche Unterschiede bestehen hingegen im Rendern von Markup.

Beim Rendern einer Razor-Seite oder -Ansicht gibt jede Razor-Codezeile HTML in Textform aus. Nach dem Rendern verwirft der Server die Instanz der Seite oder Ansicht, einschließlich aller produzierten Zustände. Tritt eine weitere Anforderung für die Seite auf, wenn etwa bei der Serverüberprüfung ein Fehler auftritt und die Zusammenfassung der Überprüfung angezeigt wird, werden folgende Aktionen ausgeführt:

  • Die gesamte Seite wird nochmals als HTML-Text gerendert.
  • Die Seite wird an den Client gesendet.

Eine Blazor-App besteht aus wiederverwendbaren Benutzeroberflächenelementen, die Komponenten genannt werden. Eine Komponente enthält C#-Code, Markup und weitere Komponenten. Wird eine Komponente gerendert, erzeugt Blazor ein Diagramm der enthaltenen Komponenten, das einem HTML- oder XML-Dokumentobjektmodell (DOM) ähnelt. Das Diagramm beinhaltet den in Eigenschaften und Feldern gespeicherten Zustand der Komponenten. Blazor wertet das Komponentendiagramm aus und erstellt eine Binärdarstellung des Markups. Folgende Aktionen können im Binärformat ausgeführt werden:

  • Umwandlung in HTML-Text (während des Prerenderings†)
  • Verwendung für eine effiziente Aktualisierung des Markups während des regulären Renderings

Prerendering: Die angeforderte Razor-Komponente wird auf dem Server in statisches HTML kompiliert und an den Client gesendet. Dort erfolgt das Rendering für den Benutzer. Nach dem Herstellen einer Verbindung zwischen Client und Server werden die vorab gerenderten statischen Elemente durch interaktive Elemente ersetzt. Durch Prerendering reagiert die App schneller auf den Benutzer.

Eine Aktualisierung der Benutzeroberfläche wird in Blazor ausgelöst durch:

  • eine Benutzerinteraktion, wie etwa das Auswählen einer Schaltfläche.
  • App-Trigger, wie etwa ein Timer.

Das Komponentendiagramm wird erneut gerendert, und für die Benutzeroberfläche wird der Unterschied diff berechnet. Dieser Unterschied stellt die kleinste Menge DOM-Änderungen dar, die zur Aktualisierung der Benutzeroberfläche auf dem Client erforderlich ist. Der Unterschied wird im Binärformat an den Client gesendet und vom Browser angewendet.

Eine Komponente wird verworfen, sobald sie der Benutzer auf dem Client wieder verlässt. Während der Interaktion mit einem Benutzer muss der Zustand der Komponente (Dienste, Ressourcen) im Arbeitsspeicher des Servers gespeichert werden. Da auf dem Server der Zustand vieler Komponenten möglicherweise gleichzeitig verwaltet werden muss, kann die Speicherausschöpfung zu einem Problem werden. Eine Anleitung zum Erstellen einer Blazor Server-App unter optimaler Verwendung des Arbeitsspeichers des Servers finden Sie unter Leitfaden zur Bedrohungsabwehr für Blazor Server in ASP.NET Core.

Leitungen

Eine Blazor Server-App basiert auf ASP.NET Core SignalR. Jeder Client kommuniziert mit dem Server über mindestens eine SignalR-Verbindung. Eine solche Verbindung ist eine Blazor-Abstraktion über SignalR-Verbindungen, die temporäre Netzwerkunterbrechungen tolerieren können. Stellt ein Blazor-Client fest, dass die SignalR-Verbindung unterbrochen ist, versucht er über eine neue SignalR-Verbindung, noch mal eine Verbindung mit dem Server herzustellen.

Jedes Browserfenster (Registerkarte des Browsers oder iframe), das über eine Blazor Server-App verbunden ist, verwendet eine SignalR-Verbindung. Darin besteht ein weiterer wesentlicher Unterschied zu typischen, auf dem Server gerenderten Apps. Bei auf dem Server gerenderten Apps bedeutet das gleichzeitige Öffnen einer App in mehreren Browserfenstern in der Regel keine zusätzlichen Ressourcenanforderungen auf dem Server. In einer Blazor Server-App erfordert jedes Browserfenster eine separate Verbindung und separate Instanzen des Komponentenzustands, die vom Server verwaltet werden müssen.

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.

In Blazor Server kann mithilfe von Code ein Verbindungshandler definiert werden, mit dem Code für Zustandsänderungen einer Benutzerverbindung ausgeführt werden kann. Weitere Informationen finden Sie unter Leitfaden für ASP.NET Core Blazor SignalR.

Benutzeroberflächenlatenz

Benutzeroberflächenlatenz bezeichnet die Zeit vom Initiieren einer Aktion bis zur Aktualisierung der Benutzeroberfläche. Je kleiner der Wert für die Benutzeroberflächenlatenz, desto dynamischer fühlt sich eine App für den Benutzer an. Bei einer Blazor Server-App wird jede Aktion an den Server gesendet, verarbeitet und ein Unterschied der Benutzeroberfläche zurückgesendet. Die Benutzeroberflächenlatenz setzt sich folglich zusammen aus der Netzwerklatenz und der Serverlatenz beim Verarbeiten der Aktion.

Bei einer Geschäftsanwendung, die ausschließlich in einem privaten Unternehmensnetzwerk verwendet wird, ist der Anteil der Netzwerklatenz an der gesamten Latenzwahrnehmung durch den Benutzer in der Regel vernachlässigbar. Bei einer über das Internet bereitgestellten App kann die Latenz für Benutzer durchaus spürbar sein, insbesondere wenn diese geografisch weit verteilt sind.

Auch die Speicherauslastung kann zur Latenzzeit einer App beitragen. Eine erhöhte Speicherauslastung führt zu einer häufigen Speicherbereinigung oder einer Auslagerung auf die Festplatte. Beide Maßnahmen reduzieren die Leistung einer App und erhöhen folglich deren Benutzeroberflächenlatenz.

Sie sollten Blazor Server-Apps so optimieren, dass die Benutzeroberflächenlatenz durch Reduzieren der Netzwerklatenz und der Speicherauslastung minimiert wird. Informationen zum Messen der Netzwerklatenz finden Sie unter Hosten und Bereitstellen von ASP.NET Core Blazor Server. Weitere Informationen zu SignalR und Blazor finden Sie unter:

Verbindung mit dem Server

Blazor Server-Apps erfordern eine aktive SignalR-Verbindung mit dem Server. Wird die Verbindung unterbrochen, versucht die App, noch mal eine Verbindung mit dem Server herzustellen. Solange der Clientzustand im Arbeitsspeicher des Servers verbleibt, wird die Clientsitzung fortgesetzt, ohne den Zustand zu verlieren.

Als Reaktion auf die erste Clientanforderung führt die Blazor Server-App ein Prerendering aus, das den Zustand der Benutzeroberfläche auf dem Server festlegt. Versucht der Client, eine SignalR-Verbindung zu erstellen, muss er noch mal mit demselben Server eine Verbindung herstellen. Blazor Server-Apps mit mehr als einem Back-End-Server sollten für SignalR-Verbindungen persistente Sitzungen implementieren.

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. Bei Azure SignalR Service werden persistente Sitzungen aktiviert, indem die Option ServerStickyMode des Diensts oder dessen Konfigurationswert auf Required festgelegt wird. Weitere Informationen finden Sie unter Hosten und Bereitstellen von ASP.NET Core Blazor Server.

Bei der Verwendung von IIS sind persistente Sitzungen mit Routing von Anwendungsanforderungen aktiviert. Weitere Informationen finden Sie unter HTTP-Lastenausgleiche mithilfe von Routing von Anwendungsanforderungen.

Zusätzliche Ressourcen

Das Webframework Blazor kann auf Clientseite im Browser in einer auf WebAssembly basierenden .NET-Runtime ( Blazor WebAssembly ) oder auf Serverseite in ASP.NET Core ( Blazor Server ) ausgeführt werden. Die App und die Komponentenmodelle sind für alle Hostingmodelle identisch.

Blazor WebAssembly

Blazor WebAssembly-Apps 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: Die Blazor-App wird in einem Benutzeroberflächenthread im Browser ausgeführt.

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ändige Blazor 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 gehostete Blazor WebAssembly-App bezeichnet. Eine gehostete Blazor WebAssembly Client -App interagiert in der Regel mit Web-API-Aufrufen oder SignalR (Verwenden von ASP.NET Core SignalR mit Blazor)über das Netzwerk mit der Back-End- Server -App.

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 besitzt folgende Vorteile:

  • Es besteht keine serverseitige .NET-Abhängigkeit. Nach dem Herunterladen auf den Client ist die App voll funktionsfähig.
  • 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.
  • Die Unterstützung für die .NET-Runtime und -Tools ist weniger ausgereift. Bei der Unterstützung und dem Debuggen in .NET Standard existieren beispielsweise Einschränkungen.

Informationen zum Erstellen einer Blazor WebAssembly-App finden Sie unter Tools für ASP.NET-Core Blazor.

Das Blazor-Modell für gehostete Apps unterstützt Docker-Container. Klicken Sie für Docker-Unterstützung in Visual Studio mit der rechten Maustaste auf das Server -Projekt einer gehosteten Blazor WebAssembly-Projektmappe, und wählen Sie Hinzufügen > Docker-Support.

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 Browser interagiert mit der (in einer ASP.NET Core-App gehosteten) App über eine SignalR-Verbindung auf dem Server.

Die ASP.NET Core-App verweist auf die Startup-Klasse der App, um folgende Aktionen durchzuführen:

  • Hinzufügen serverseitiger Dienste
  • Hinzufügen der App zur Pipeline für die Anforderungsverarbeitung

Auf dem Client stellt das blazor.server.js-Skript 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 werden in vollem Umfang genutzt, einschließlich aller mit .NET Core kompatiblen APIs.
  • 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.

Wichtig

Als Reaktion auf die erste Clientanforderung führt die Blazor Server-App ein Prerendering aus, das den Zustand der Benutzeroberfläche auf dem Server festlegt. Versucht der Client, eine SignalR-Verbindung zu erstellen, muss er mit demselben Server erneut eine Verbindung herstellen. Blazor Server-Apps mit mehr als einem Back-End-Server sollten für SignalR-Verbindungen persistente Sitzungen implementieren. Weitere Informationen finden Sie im Abschnitt Verbindung mit dem Server.

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.
  • Die Skalierbarkeit ist bei Apps mit vielen Benutzern schwierig. Der Server muss eine Vielzahl von Clientverbindungen verwalten und Clientzustände verarbeiten.
  • 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).

Informationen zum Erstellen einer Blazor Server-App finden Sie unter Tools für ASP.NET-Core Blazor.

Das Blazor Server-App-Modell unterstützt Docker-Container. Klicken Sie für Docker-Unterstützung in Visual Studio mit der rechten Maustaste auf das Projekt in Visual Studio, und wählen Sie Hinzufügen > Docker-Unterstützung aus.

Vergleich mit einer auf dem Server gerenderten Benutzeroberfläche

Die Unterschiede zwischen Blazor Server-Apps und traditionellen Modellen beim Rendern von Benutzeroberflächen in ASP.NET Core-Apps mit Razor-Ansichten oder Razor Pages zu kennen ist entscheidend. Bei beiden Modellen wird zum Beschreiben von HTML-Inhalt die Razor-Syntax verwendet. Deutliche Unterschiede bestehen hingegen im Rendern von Markup.

Beim Rendern einer Razor-Seite oder -Ansicht gibt jede Razor-Codezeile HTML in Textform aus. Nach dem Rendern verwirft der Server die Instanz der Seite oder Ansicht, einschließlich aller produzierten Zustände. Tritt eine weitere Anforderung für die Seite auf, wenn etwa bei der Serverüberprüfung ein Fehler auftritt und die Zusammenfassung der Überprüfung angezeigt wird, werden folgende Aktionen ausgeführt:

  • Die gesamte Seite wird nochmals als HTML-Text gerendert.
  • Die Seite wird an den Client gesendet.

Eine Blazor-App besteht aus wiederverwendbaren Benutzeroberflächenelementen, die Komponenten genannt werden. Eine Komponente enthält C#-Code, Markup und weitere Komponenten. Wird eine Komponente gerendert, erzeugt Blazor ein Diagramm der enthaltenen Komponenten, das einem HTML- oder XML-Dokumentobjektmodell (DOM) ähnelt. Das Diagramm beinhaltet den in Eigenschaften und Feldern gespeicherten Zustand der Komponenten. Blazor wertet das Komponentendiagramm aus und erstellt eine Binärdarstellung des Markups. Folgende Aktionen können im Binärformat ausgeführt werden:

  • Umwandlung in HTML-Text (während des Prerenderings†)
  • Verwendung für eine effiziente Aktualisierung des Markups während des regulären Renderings

Prerendering: Die angeforderte Razor-Komponente wird auf dem Server in statisches HTML kompiliert und an den Client gesendet. Dort erfolgt das Rendering für den Benutzer. Nach dem Herstellen einer Verbindung zwischen Client und Server werden die vorab gerenderten statischen Elemente durch interaktive Elemente ersetzt. Durch Prerendering reagiert die App schneller auf den Benutzer.

Eine Aktualisierung der Benutzeroberfläche wird in Blazor ausgelöst durch:

  • eine Benutzerinteraktion, wie etwa das Auswählen einer Schaltfläche.
  • App-Trigger, wie etwa ein Timer.

Das Komponentendiagramm wird erneut gerendert, und für die Benutzeroberfläche wird der Unterschied diff berechnet. Dieser Unterschied stellt die kleinste Menge DOM-Änderungen dar, die zur Aktualisierung der Benutzeroberfläche auf dem Client erforderlich ist. Der Unterschied wird im Binärformat an den Client gesendet und vom Browser angewendet.

Eine Komponente wird verworfen, sobald sie der Benutzer auf dem Client wieder verlässt. Während der Interaktion mit einem Benutzer muss der Zustand der Komponente (Dienste, Ressourcen) im Arbeitsspeicher des Servers gespeichert werden. Da auf dem Server der Zustand vieler Komponenten möglicherweise gleichzeitig verwaltet werden muss, kann die Speicherausschöpfung zu einem Problem werden. Eine Anleitung zum Erstellen einer Blazor Server-App unter optimaler Verwendung des Arbeitsspeichers des Servers finden Sie unter Leitfaden zur Bedrohungsabwehr für Blazor Server in ASP.NET Core.

Leitungen

Eine Blazor Server-App basiert auf ASP.NET Core SignalR. Jeder Client kommuniziert mit dem Server über mindestens eine SignalR-Verbindung. Eine solche Verbindung ist eine Blazor-Abstraktion über SignalR-Verbindungen, die temporäre Netzwerkunterbrechungen tolerieren können. Stellt ein Blazor-Client fest, dass die SignalR-Verbindung unterbrochen ist, versucht er über eine neue SignalR-Verbindung, noch mal eine Verbindung mit dem Server herzustellen.

Jedes Browserfenster (Registerkarte des Browsers oder iframe), das über eine Blazor Server-App verbunden ist, verwendet eine SignalR-Verbindung. Darin besteht ein weiterer wesentlicher Unterschied zu typischen, auf dem Server gerenderten Apps. Bei auf dem Server gerenderten Apps bedeutet das gleichzeitige Öffnen einer App in mehreren Browserfenstern in der Regel keine zusätzlichen Ressourcenanforderungen auf dem Server. In einer Blazor Server-App erfordert jedes Browserfenster eine separate Verbindung und separate Instanzen des Komponentenzustands, die vom Server verwaltet werden müssen.

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.

In Blazor Server kann mithilfe von Code ein Verbindungshandler definiert werden, mit dem Code für Zustandsänderungen einer Benutzerverbindung ausgeführt werden kann. Weitere Informationen finden Sie unter Leitfaden für ASP.NET Core Blazor SignalR.

Benutzeroberflächenlatenz

Benutzeroberflächenlatenz bezeichnet die Zeit vom Initiieren einer Aktion bis zur Aktualisierung der Benutzeroberfläche. Je kleiner der Wert für die Benutzeroberflächenlatenz, desto dynamischer fühlt sich eine App für den Benutzer an. Bei einer Blazor Server-App wird jede Aktion an den Server gesendet, verarbeitet und ein Unterschied der Benutzeroberfläche zurückgesendet. Die Benutzeroberflächenlatenz setzt sich folglich zusammen aus der Netzwerklatenz und der Serverlatenz beim Verarbeiten der Aktion.

Bei einer Geschäftsanwendung, die ausschließlich in einem privaten Unternehmensnetzwerk verwendet wird, ist der Anteil der Netzwerklatenz an der gesamten Latenzwahrnehmung durch den Benutzer in der Regel vernachlässigbar. Bei einer über das Internet bereitgestellten App kann die Latenz für Benutzer durchaus spürbar sein, insbesondere wenn diese geografisch weit verteilt sind.

Auch die Speicherauslastung kann zur Latenzzeit einer App beitragen. Eine erhöhte Speicherauslastung führt zu einer häufigen Speicherbereinigung oder einer Auslagerung auf die Festplatte. Beide Maßnahmen reduzieren die Leistung einer App und erhöhen folglich deren Benutzeroberflächenlatenz.

Sie sollten Blazor Server-Apps so optimieren, dass die Benutzeroberflächenlatenz durch Reduzieren der Netzwerklatenz und der Speicherauslastung minimiert wird. Informationen zum Messen der Netzwerklatenz finden Sie unter Hosten und Bereitstellen von ASP.NET Core Blazor Server. Weitere Informationen zu SignalR und Blazor finden Sie unter:

Verbindung mit dem Server

Blazor Server-Apps erfordern eine aktive SignalR-Verbindung mit dem Server. Wird die Verbindung unterbrochen, versucht die App, noch mal eine Verbindung mit dem Server herzustellen. Solange der Clientzustand im Arbeitsspeicher des Servers verbleibt, wird die Clientsitzung fortgesetzt, ohne den Zustand zu verlieren.

Als Reaktion auf die erste Clientanforderung führt die Blazor Server-App ein Prerendering aus, das den Zustand der Benutzeroberfläche auf dem Server festlegt. Versucht der Client, eine SignalR-Verbindung zu erstellen, muss er noch mal mit demselben Server eine Verbindung herstellen. Blazor Server-Apps mit mehr als einem Back-End-Server sollten für SignalR-Verbindungen persistente Sitzungen implementieren.

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. Bei Azure SignalR Service werden persistente Sitzungen aktiviert, indem die Option ServerStickyMode des Diensts oder dessen Konfigurationswert auf Required festgelegt wird. Weitere Informationen finden Sie unter Hosten und Bereitstellen von ASP.NET Core Blazor Server.

Bei der Verwendung von IIS sind persistente Sitzungen mit Routing von Anwendungsanforderungen aktiviert. Weitere Informationen finden Sie unter HTTP-Lastenausgleiche mithilfe von Routing von Anwendungsanforderungen.

Zusätzliche Ressourcen

Das Webframework Blazor kann auf Clientseite im Browser in einer auf WebAssembly basierenden .NET-Runtime ( Blazor WebAssembly ) oder auf Serverseite in ASP.NET Core ( Blazor Server ) ausgeführt werden. Die App und die Komponentenmodelle sind für alle Hostingmodelle identisch.

Blazor WebAssembly

Blazor WebAssembly-Apps 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: Die Blazor-App wird in einem Benutzeroberflächenthread im Browser ausgeführt.

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ändige Blazor 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 gehostete Blazor WebAssembly-App bezeichnet. Eine gehostete Blazor WebAssembly Client -App interagiert in der Regel mit Web-API-Aufrufen oder SignalR (Verwenden von ASP.NET Core SignalR mit Blazor)über das Netzwerk mit der Back-End- Server -App.

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 besitzt folgende Vorteile:

  • Es besteht keine serverseitige .NET-Abhängigkeit. Nach dem Herunterladen auf den Client ist die App voll funktionsfähig.
  • 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.
  • Die Unterstützung für die .NET-Runtime und -Tools ist weniger ausgereift. Bei der Unterstützung und dem Debuggen in .NET Standard existieren beispielsweise Einschränkungen.

Informationen zum Erstellen einer Blazor WebAssembly-App finden Sie unter Tools für ASP.NET-Core Blazor.

Das Blazor-Modell für gehostete Apps unterstützt Docker-Container. Klicken Sie für Docker-Unterstützung in Visual Studio mit der rechten Maustaste auf das Server -Projekt einer gehosteten Blazor WebAssembly-Projektmappe, und wählen Sie Hinzufügen > Docker-Support.

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 Browser interagiert mit der (in einer ASP.NET Core-App gehosteten) App über eine SignalR-Verbindung auf dem Server.

Die ASP.NET Core-App verweist auf die Startup-Klasse der App, um folgende Aktionen durchzuführen:

  • Hinzufügen serverseitiger Dienste
  • Hinzufügen der App zur Pipeline für die Anforderungsverarbeitung

Auf dem Client stellt das blazor.server.js-Skript 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 werden in vollem Umfang genutzt, einschließlich aller mit .NET Core kompatiblen APIs.
  • 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.

Wichtig

Als Reaktion auf die erste Clientanforderung führt die Blazor Server-App ein Prerendering aus, das den Zustand der Benutzeroberfläche auf dem Server festlegt. Versucht der Client, eine SignalR-Verbindung zu erstellen, muss er mit demselben Server erneut eine Verbindung herstellen. Blazor Server-Apps mit mehr als einem Back-End-Server sollten für SignalR-Verbindungen persistente Sitzungen implementieren. Weitere Informationen finden Sie im Abschnitt Verbindung mit dem Server.

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.
  • Die Skalierbarkeit ist bei Apps mit vielen Benutzern schwierig. Der Server muss eine Vielzahl von Clientverbindungen verwalten und Clientzustände verarbeiten.
  • 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).

Informationen zum Erstellen einer Blazor Server-App finden Sie unter Tools für ASP.NET-Core Blazor.

Das Blazor Server-App-Modell unterstützt Docker-Container. Klicken Sie für Docker-Unterstützung in Visual Studio mit der rechten Maustaste auf das Projekt in Visual Studio, und wählen Sie Hinzufügen > Docker-Unterstützung aus.

Vergleich mit einer auf dem Server gerenderten Benutzeroberfläche

Die Unterschiede zwischen Blazor Server-Apps und traditionellen Modellen beim Rendern von Benutzeroberflächen in ASP.NET Core-Apps mit Razor-Ansichten oder Razor Pages zu kennen ist entscheidend. Bei beiden Modellen wird zum Beschreiben von HTML-Inhalt die Razor-Syntax verwendet. Deutliche Unterschiede bestehen hingegen im Rendern von Markup.

Beim Rendern einer Razor-Seite oder -Ansicht gibt jede Razor-Codezeile HTML in Textform aus. Nach dem Rendern verwirft der Server die Instanz der Seite oder Ansicht, einschließlich aller produzierten Zustände. Tritt eine weitere Anforderung für die Seite auf, wenn etwa bei der Serverüberprüfung ein Fehler auftritt und die Zusammenfassung der Überprüfung angezeigt wird, werden folgende Aktionen ausgeführt:

  • Die gesamte Seite wird nochmals als HTML-Text gerendert.
  • Die Seite wird an den Client gesendet.

Eine Blazor-App besteht aus wiederverwendbaren Benutzeroberflächenelementen, die Komponenten genannt werden. Eine Komponente enthält C#-Code, Markup und weitere Komponenten. Wird eine Komponente gerendert, erzeugt Blazor ein Diagramm der enthaltenen Komponenten, das einem HTML- oder XML-Dokumentobjektmodell (DOM) ähnelt. Das Diagramm beinhaltet den in Eigenschaften und Feldern gespeicherten Zustand der Komponenten. Blazor wertet das Komponentendiagramm aus und erstellt eine Binärdarstellung des Markups. Folgende Aktionen können im Binärformat ausgeführt werden:

  • Umwandlung in HTML-Text (während des Prerenderings†)
  • Verwendung für eine effiziente Aktualisierung des Markups während des regulären Renderings

Prerendering: Die angeforderte Razor-Komponente wird auf dem Server in statisches HTML kompiliert und an den Client gesendet. Dort erfolgt das Rendering für den Benutzer. Nach dem Herstellen einer Verbindung zwischen Client und Server werden die vorab gerenderten statischen Elemente durch interaktive Elemente ersetzt. Durch Prerendering reagiert die App schneller auf den Benutzer.

Eine Aktualisierung der Benutzeroberfläche wird in Blazor ausgelöst durch:

  • eine Benutzerinteraktion, wie etwa das Auswählen einer Schaltfläche.
  • App-Trigger, wie etwa ein Timer.

Das Komponentendiagramm wird erneut gerendert, und für die Benutzeroberfläche wird der Unterschied diff berechnet. Dieser Unterschied stellt die kleinste Menge DOM-Änderungen dar, die zur Aktualisierung der Benutzeroberfläche auf dem Client erforderlich ist. Der Unterschied wird im Binärformat an den Client gesendet und vom Browser angewendet.

Eine Komponente wird verworfen, sobald sie der Benutzer auf dem Client wieder verlässt. Während der Interaktion mit einem Benutzer muss der Zustand der Komponente (Dienste, Ressourcen) im Arbeitsspeicher des Servers gespeichert werden. Da auf dem Server der Zustand vieler Komponenten möglicherweise gleichzeitig verwaltet werden muss, kann die Speicherausschöpfung zu einem Problem werden. Eine Anleitung zum Erstellen einer Blazor Server-App unter optimaler Verwendung des Arbeitsspeichers des Servers finden Sie unter Leitfaden zur Bedrohungsabwehr für Blazor Server in ASP.NET Core.

Leitungen

Eine Blazor Server-App basiert auf ASP.NET Core SignalR. Jeder Client kommuniziert mit dem Server über mindestens eine SignalR-Verbindung. Eine solche Verbindung ist eine Blazor-Abstraktion über SignalR-Verbindungen, die temporäre Netzwerkunterbrechungen tolerieren können. Stellt ein Blazor-Client fest, dass die SignalR-Verbindung unterbrochen ist, versucht er über eine neue SignalR-Verbindung, noch mal eine Verbindung mit dem Server herzustellen.

Jedes Browserfenster (Registerkarte des Browsers oder iframe), das über eine Blazor Server-App verbunden ist, verwendet eine SignalR-Verbindung. Darin besteht ein weiterer wesentlicher Unterschied zu typischen, auf dem Server gerenderten Apps. Bei auf dem Server gerenderten Apps bedeutet das gleichzeitige Öffnen einer App in mehreren Browserfenstern in der Regel keine zusätzlichen Ressourcenanforderungen auf dem Server. In einer Blazor Server-App erfordert jedes Browserfenster eine separate Verbindung und separate Instanzen des Komponentenzustands, die vom Server verwaltet werden müssen.

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.

In Blazor Server kann mithilfe von Code ein Verbindungshandler definiert werden, mit dem Code für Zustandsänderungen einer Benutzerverbindung ausgeführt werden kann. Weitere Informationen finden Sie unter Leitfaden für ASP.NET Core Blazor SignalR.

Benutzeroberflächenlatenz

Benutzeroberflächenlatenz bezeichnet die Zeit vom Initiieren einer Aktion bis zur Aktualisierung der Benutzeroberfläche. Je kleiner der Wert für die Benutzeroberflächenlatenz, desto dynamischer fühlt sich eine App für den Benutzer an. Bei einer Blazor Server-App wird jede Aktion an den Server gesendet, verarbeitet und ein Unterschied der Benutzeroberfläche zurückgesendet. Die Benutzeroberflächenlatenz setzt sich folglich zusammen aus der Netzwerklatenz und der Serverlatenz beim Verarbeiten der Aktion.

Bei einer Geschäftsanwendung, die ausschließlich in einem privaten Unternehmensnetzwerk verwendet wird, ist der Anteil der Netzwerklatenz an der gesamten Latenzwahrnehmung durch den Benutzer in der Regel vernachlässigbar. Bei einer über das Internet bereitgestellten App kann die Latenz für Benutzer durchaus spürbar sein, insbesondere wenn diese geografisch weit verteilt sind.

Auch die Speicherauslastung kann zur Latenzzeit einer App beitragen. Eine erhöhte Speicherauslastung führt zu einer häufigen Speicherbereinigung oder einer Auslagerung auf die Festplatte. Beide Maßnahmen reduzieren die Leistung einer App und erhöhen folglich deren Benutzeroberflächenlatenz.

Sie sollten Blazor Server-Apps so optimieren, dass die Benutzeroberflächenlatenz durch Reduzieren der Netzwerklatenz und der Speicherauslastung minimiert wird. Informationen zum Messen der Netzwerklatenz finden Sie unter Hosten und Bereitstellen von ASP.NET Core Blazor Server. Weitere Informationen zu SignalR und Blazor finden Sie unter:

Verbindung mit dem Server

Blazor Server-Apps erfordern eine aktive SignalR-Verbindung mit dem Server. Wird die Verbindung unterbrochen, versucht die App, noch mal eine Verbindung mit dem Server herzustellen. Solange der Clientzustand im Arbeitsspeicher des Servers verbleibt, wird die Clientsitzung fortgesetzt, ohne den Zustand zu verlieren.

Als Reaktion auf die erste Clientanforderung führt die Blazor Server-App ein Prerendering aus, das den Zustand der Benutzeroberfläche auf dem Server festlegt. Versucht der Client, eine SignalR-Verbindung zu erstellen, muss er noch mal mit demselben Server eine Verbindung herstellen. Blazor Server-Apps mit mehr als einem Back-End-Server sollten für SignalR-Verbindungen persistente Sitzungen implementieren.

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. Bei Azure SignalR Service werden persistente Sitzungen aktiviert, indem die Option ServerStickyMode des Diensts oder dessen Konfigurationswert auf Required festgelegt wird. Weitere Informationen finden Sie unter Hosten und Bereitstellen von ASP.NET Core Blazor Server.

Bei der Verwendung von IIS sind persistente Sitzungen mit Routing von Anwendungsanforderungen aktiviert. Weitere Informationen finden Sie unter HTTP-Lastenausgleiche mithilfe von Routing von Anwendungsanforderungen.

Zusätzliche Ressourcen