Blazor-Interaktivität

Blazor ermöglicht es, ein Portal in einem von drei Interaktivitätsmodi auszusenden – Server, WebAssembly oder Auto. Der Modus wählt, wie interaktive Komponenten laufen (über eine SignalR-Verbindung auf dem Server, als kompilierte .NET im Browser oder beides) und entscheidet, was in deinem Projektlayout generiert wird. Power Portals Pro läuft unter allen dreien Systemen korrekt; Die Unterschiede liegen in der Bereitstellungsform und Projektverdrahtung, nicht in den Framework-Funktionen.

Die drei Modi

Server

Interaktive Komponenten werden auf dem Server ausgeführt. Jeder verbundene Benutzer hält eine offene SignalR-Verbindung zurück zum Host, und jedes UI-Ereignis wird zum Server rundgekehrt.

• Kleinster Client-Download. Der Browser erhält einfaches HTML und einen kleinen SignalR-Loader – keine .NET-Laufzeit wird an den Client ausgeliefert.
• Volle Serverfähigkeiten. Komponenten injizieren jeden serverseitigen Dienst direkt (Dataverse-Client, Konfiguration, Dateisystem), ohne HTTP zu verwenden.
• Die einfachste Bereitstellung. Einer ASP.NET Core-Host, kein separates WebAssembly-Bundle zum Veröffentlichen.

Kompromisse:

• Staatlicher Wirt. Der Schaltkreis jedes Nutzers ist an eine einzelne Serverinstanz gebunden; Horizontale Skalierung benötigt klebrige Sitzungen, und ein Neustart des Hosts bricht jede aktive Sitzung ab.
• UI-Latenz folgt der Netzwerklatenz. Jeder Klick, jeder Tastendruck und jeder Scroll-Wechsel zum Server, sodass Nutzer auf Links mit hoher Latenz die App als träge empfinden.

WebAssembly

Interaktive Komponenten laufen im Browser als kompilierter .NET-Code. Der Job des Servers schrumpft auf die Bereitstellung statischer Dateien und der HTTP-API-Endpunkte des Frameworks unter /api/auth/* und /api/*.

• Zustandsloser Server. Der Host skaliert horizontal ohne Sticky-Sitzungen, Neustarts verursachen keine sichtbare Störungen, und die Speicherkosten pro Benutzer auf dem Server liegen nahezu bei null.
• Schnelle Benutzeroberfläche. Die meisten Interaktionen bleiben im Browser – kein SignalR-Roundtrip pro Klick – sodass sich die App sofort anfühlt, sobald das Bundle geladen ist.
• Offline-fähig. Ein geladenes Portal rendert und validiert weiterhin gegen zwischengespeicherte Daten, selbst wenn das Netzwerk ausfällt, und synchronisiert sich bei der Rückkehr mit der API zurück.

Kompromisse:

• Erster Download. Die .NET-Laufzeit, Framework-Assemblies und der Code deines Portals werden beim ersten Laden (komprimiert, oft ein paar MB) in den Browser geliefert. Nachfolgende Besuche laden aus dem Browser-Cache.
• API-Oberfläche erforderlich. Alles, was die Benutzeroberfläche vom Server benötigt, muss als HTTP-Endpunkt bereitgestellt werden. Power Portals Pro stellt die Daten- und Authentifizierungsendpunkte direkt zur Verfügung; Benutzerdefinierte Serverlogik benötigt eigene Controller oder Endpunkte mit minimaler API.
• Browser-seitige Leistung. CPU-intensive Arbeit (große Gitter, komplexe Diagrammberechnungen) läuft mit WebAssembly-Geschwindigkeit, was schnell, aber langsamer ist als das native serverseitige .NET.

Auto

Die erste Farbe kommt vom Server (sodass der Nutzer Inhalte sofort sieht) und die Laufzeit wechselt transparent zu WebAssembly, sobald das Client-Bundle den Download abgeschlossen hat. Auto = zuerst Server, danach WebAssembly, auf denselben Routen.

• Beste wahrgenommene Last + beste stationäre UX. Nutzer erhalten sofort das erste Paint ohne das WASM-Bundle zu warten und genießen dann die schnellen Interaktionen von WebAssembly, sobald die Laufzeit im Browser zwischengespeichert ist.
• Einzelne Einsätze. Ein Host, ein Veröffentlichungsschritt – wie bei WebAssembly, wobei die Serverlaufzeit für das Prerendering übernommen wird.

Kompromisse:

• Das komplexeste Projektlayout. Beide Laufzeiten müssen verdrahtet sein; Komponenten müssen unter beiden Renderern korrekt funktionieren (keine Server-Only-Dienste, die in gemeinsame Komponenten eingespeist werden).
• Kurzes Server-gerendertes Fenster. Beim ersten Besuch wird die Seite serverseitig gerendert, bis der WASM-Wechsel abgeschlossen ist – die Vorlage von Power Portals Pro verbirgt diesen Übergang mit einem Lade-Overlay, damit Nutzer den Zwischenzustand nicht sehen.

Tipp

Diese Dokumentationsseite läuft im Auto-Modus. Öffne beim ersten Laden den Netzwerk-Tab der Browser-Entwicklungstools, und du siehst, dass zuerst das servergerenderte HTML ankommt, dann der WASM-Bundle-Stream in über ein oder zwei Sekunden – danach hören die Navigationen auf, den Server für HTML zu bedienen.

Welchen soll man wählen

Grobe Faustregeln, wenn es keine spezifische Einschränkung gibt, die eine Entscheidung erzwingt:

• Wählen Sie Server , wenn das Portal wenige gleichzeitige Nutzer hat, innerhalb eines Firmennetzwerks mit stabilen Verbindungen läuft oder Ihr Team neu bei Blazor ist und das einfachste mentale Modell möchte.
• Wählen Sie WebAssembly , wenn das Portal kundenorientiert ist und hohe Nebenzeitigkeit bietet, Ihre Hosting-Rechnung mit aktiven Sitzungen skaliert oder Sie Offline-Verhalten benötigen. Akzeptieren Sie die Anfangskosten des Downloads als einmaligen Treffer pro Besucher.
• Wähle Auto, wenn du den WebAssembly-Steady State willst, ohne die First-Paint-Latenz für das Bundle herunterzuladen. Die meisten Produktionsportale landen hier.

Spickzettel

Was sich zwischen den drei Modi ändert, Datei für Datei? Nutzen Sie dies als Referenz, wenn Sie ein generiertes Projekt mit einer der Vorlagen vergleichen oder eine Diskrepanz nach einem manuellen Wechsel verfolgen.

Projektlayout

Alle drei Modi erzeugen ein Server-Host-Projekt UND ein Schwesterprojekt .Client . Was sich unterscheidet, ist das .ClientSDK und ob es tatsächlich in ein WebAssembly-Bundle kompiliert wurde.

• Server — .Client verwendet Microsoft.NET.Sdk.Razor; es ist eine Klassenbibliothek, die gemeinsame Komponenten enthält, aber nicht als WASM veröffentlicht wird.
• WebAssembly — .Client verwendet Microsoft.NET.Sdk.BlazorWebAssembly mit seinem eigenen Program.cs, kompiliert in ein herunterladbares Bundle.
• Auto – wie WebAssembly: Microsoft.NET.Sdk.BlazorWebAssembly mit eigenem Program.cs.

.csproj Unterschiede

Das SDK des .Client Projekts ändert sich, und die WebAssembly-spezifischen Framework-Pakete erscheinen nur, wenn der Host tatsächlich WASM ausführt:

Zusätzliche Paketreferenzen, wenn WebAssembly oder Auto aktiv ist:

Server Program.cs — Service Registration

AddRazorComponents() wählt die passenden Visual-Mode-Komponentenpaare basierend darauf, welche Builder-Methoden verkettet sind:

Server Program.cs — Endpunkt-Mapping

MapRazorComponents<App>() verkettet die passenden Endpunkte im Rendermodus:

App.razor — Pro-Route-Render-Policy

Der PageRenderMode Getter entscheidet App.razor , welchen Renderer jede Route verwendet. Server-Hosts geben Server überall zurück; WebAssembly- und Auto-Hosts müssen die /Account/* Routen explizit pinnen, sodass das ausschließlich WASM-basierte IAuthService System aufgelöst wird:

Warum /Account/* angepinnt ist

Die erste Lackierung von Auto läuft unter dem Server-Renderer, aber die Kontoseiten IAuthService sind nur im DI-Graphen des WASM-Clients registriert. Ohne den expliziten Pin an InteractiveWebAssemblyRenderMode(prerender: false), kann ein Autohost beim Cold-Session-Prerendering nicht auflösen [Inject] IAuthService . prerender: false Überspringt den serverseitigen Prerender-Schritt komplett, sodass die Seite nur einmal rendert, nämlich in der WASM-Laufzeit.

. Client/Program.cs – Nur bei Interaktion

Server-only-Hosts haben .Client/Program.cs überhaupt keine (es .Client handelt sich um eine Razor-Klassenbibliothek). WebAssembly- und Auto-Hosts enthalten diese Datei, die die WASM-Laufzeit einrichtet, die HttpClient mit Cookie-Zugangsdaten weiterleitet, die WASM-Client-Dienste von Power Portals Pro registriert und beim Start die Crosscutting-Lokalisierung vorabruft:

Identitäts- / Kontoseiten

Power Portals Pro liefert zwei parallele Sets von Account-Seiten – eine für jeden Render-Kontext. Welche Menge in deinem Projekt ist, hängt vom Modus des Hosts ab:

• Server — Server-gerenderte Razor-Seiten unter Components/Account/Pages/ direkter Nutzung UserManager . Formular-Post-Endpunkte registriert über app.MapAdditionalIdentityEndpoints().
• WebAssembly / Auto — interaktive Seiten unter .Client/Pages/Account/ Verwendung des Framework-Wrappers IAuthService . JSON-Endpunkte wurden über app.MapAuthEndpoints<PortalUser>() Handle Login, Register, Manage/* und External-Login-Abschluss als application/json Aufrufe registriert.

Nächste Schritte

Wenn Sie bereits ein Projekt in einem Modus haben und in einen anderen konvertieren möchten, sehen Sie sich die Switch Blazor Interactivity-Seite für die Datei-für-Datei-Änderungen an.