Blazor ist ein Framework von Microsoft, um interaktive Web-Frontends mit C# statt mit JavaScript zu erstellen. Es wurde 2019 im Rahmen von .NET Core 3.0 veröffentlicht. Seitdem wird es konstant weiterentwickelt. So wird es beispielsweise auch mit .NET 8 weitere Verbesserungen geben [1]. Parallel zu den Features von Blazor reift auch das Ökosystem an hilfreichen Komponenten und Bibliotheken. Mittlerweile hat sich das Framework bewährt und den anfänglichen Hype hinter sich gelassen. Daher soll nachträglich genauer betrachtet und erläutert werden wo Blazor ggf. im industriellen Kontext eingesetzt werden kann.
C# statt JavaScript – Die Gestaltung der UI
@page "/counter"
<PageTitle>Counter</PageTitle>
<h1>Counter</h1>
<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
Abbildung 1: Codebeispiel mit Razor-Syntax für eine Blazor-Website
Blazor verwendet die sogenannte Razor-Syntax. Diese besteht aus HTML, speziellem Razor-Markup und C#. Mit Grundkenntnissen in HTML findet man sich darin auch als C#-Entwickler schnell zurecht. JavaScript spielt bei Blazor im Normalfall nur im Hintergrund eine Rolle und wird in den meisten Fällen nicht direkt eingesetzt. Ausnahmen von dieser Regel sind z.B. spezielle Interaktionen mit dem Browser oder um JavaScript-Bibliotheken anzusprechen. Gerade für beliebte JavaScript-Bibliotheken gibt es jedoch auch immer häufiger entsprechende Wrapper, welche durch die Community bereitgestellt werden.
Hosting-Modelle von Blazor
Für Blazor-Apps gibt es drei Hosting-Modelle, die bestimmen, wie eine Blazor-App funktioniert, welche Funktionen zur Verfügung stehen und welche Einschränkungen es gibt.
Blazor Server – Server-Side Rendering
In diesem Fall wird die Webseite in einer ASP.NET Core-App auf dem Server dynamisch erzeugt und das HTML an den Browser übertragen. Durch das Rendering auf dem Server steht die gesamte Funktionalität des Backends zur Verfügung. Für jede Interaktion zwischen Browser und Server wird eine aktive SignalR-Verbindung benötigt. Die Latenz dieser Netzwerkverbindung wirkt sich direkt auf die Reaktionszeit der UI aus. Außerdem wird die Performance der Blazor-Anwendung durch die Performance des Servers begrenzt, was zum Beispiel viele gleichzeitige Client-Verbindungen kostspielig macht.
Dieses Hosting-Modell ist gut geeignet, wenn …
- Anwendungen eine überschaubare Anzahl von Nutzern bedienen.
- Serverperformance, Netzwerklatenz und Offline-Szenarios keine Rolle spielen.
- spezielle Anforderungen bestehen, die nur im Backend umgesetzt werden können. Beispiel: Authentifizierung von Usern auf der Basis des Windows-Logins
Blazor WebAssembly – Client-Side Rendering
Die Anwendung wird zusammen mit der .NET-Runtime von einem beliebigen Webserver in den Browser geladen. Diese Runtime wird in der WebAssembly-Umgebung des Browsers ausgeführt und rendert anschließend die Webseite lokal. Nach dem Download der gesamten App vom Server laufen Blazor WebAssembly-Apps somit komplett im Browser. Das initiale Laden der App dauert jedoch einige Sekunden, da hier – je nach App – viele Daten übertragen werden müssen (bereits für die Template-App von Microsoft sind es 10 MB). Blazor WebAssembly entspricht der Funktionsweise von gängigen Single Page Application-Frameworks (SPA) wie React oder Angular.
Da die App komplett im Browser läuft, ist sie nicht auf einen Server angewiesen, aber auf die Funktionalitäten des Browsers und der WebAssembly-Runtime beschränkt, was zum Beispiel die Interaktion mit lokalen Ressourcen auf dem Client (Dateisystem etc.) und einige .NET-APIs limitiert.
Dieses Hosting-Modell ist gut geeignet, wenn …
- keine Firewall den Download der App (DLLs!) in den Browser verhindert.1
- Download-Größe und Startzeit irrelevant sind oder vom Benutzer akzeptiert werden.
- eine reichhaltige und interaktive Single Page Application benötigt wird.
- alle Funktionalitäten im Browser realisierbar sind.
Blazor Hybrid
Die Blazor-App wird lokal auf dem Desktop (in .NET MAUI, WPF oder Windows Forms) ausgeführt und in einem eingebetteten WebView gerendert. Die Wortwahl ‘Hybrid’ bezieht sich also auf die Verschmelzung von Webtechnologie (Blazor) mit Desktop- oder Mobile-Frameworks. Da die App lokal läuft, hat sie auch vollen Zugriff auf Funktionalitäten des Clients.
Dieses Hosting-Modell ist gut geeignet, wenn …
- Blazor-Komponenten auf dem Desktop wiederverwendet werden sollen
- Desktop-Anwendungen Schritt für Schritt auf Webtechnologie umgestellt werden sollen
Das im Herbst 2023 erscheinende .NET 8 wird ein weiteres Hosting-Modell einführen, das einen Mittelweg zwischen Blazor Server und WebAssembly darstellt. Damit sollen Performance-Vorteile des Renderns von statischen Inhalten auf dem Webserver mit der Interaktivität von Single Page Applications verbunden werden und die Ladezeit der Apps verringert werden [2].
Wo kann Blazor in der Industrie zum Einsatz kommen?
Für die Bewertung von sinnvollen Anwendungsfällen müssen wir uns die Vorteile von Blazor gegenüber anderen Web-UI-Frameworks wie Angular oder React ansehen.
- Blazor gehört zum ASP.NET Core-Universum und kann damit vorhandene .NET-Bibliotheken einbinden und weiterverwenden.
- Da Blazor für C#-Entwickler entwickelt wurde, passt es zu Teams, deren Kompetenzen bisher vor allem im .NET-Backend-Bereich liegen.
- Blazor passt gut zu Projekten, in denen der Fokus eher auf dem Backend mit komplexer Geschäftslogik und umfangreicher Datenbank liegt. Beispiel: Forms-over-Data-Anwendungen mit umfangreichen Formularen, aber ansonsten geringer UI-Funktionalität
Anwendungsfall 1: Hintergrund-Anwendung mit lokaler Management-Oberfläche
Eine .NET-Anwendung, die auf einem Rechner als Dienst läuft, soll eine einfache lokal verfügbare UI bekommen, mit der die Software konfiguriert und administriert werden kann.
Für diesen Fall empfiehlt sich Blazor mit dem Hosting-Modell Blazor Server, da in der Blazor-Anwendung einfach auf Komponenten der .NET-Hintergrundanwendung zugegriffen werden kann. Abstraktionsschichten wie eine REST-API sind nicht nötig. Netzwerkprobleme durch Firewall, hohe Latenz oder fehlende Verfügbarkeit sind ausgeschlossen. Durch die geringe Hürde beim Umstieg auf Blazor können auch Backend-Entwickler mit geringen Kenntnissen von Web-Techniken die einfache Web-UI umsetzen.
Anwendungsfall 2: Informationssystem
Ein System stellt Informationen für Anlagenwartung zur Verfügung. Die UI soll an mehreren festen Stationen und mobil auf Laptop oder Tablet zur Verfügung stehen, um auch vor Ort an der Maschine auf die Daten zugreifen zu können.
Hier empfiehlt sich Blazor WebAssembly. Für den mobilen Zugriff in einer Anlage muss ein Offline-Szenario unterstützt werden, bei dem die Daten auch ohne Verbindung lokal gelesen und bearbeitet werden können. Die Daten werden zu einem späteren Zeitpunkt mit dem Backend synchronisiert. Blazor WebAssembly unterstützt auch die Funktionen für eine Progressive Web App (PWA), die sich lokal installieren lässt. Die Startdauer der App ist erhöht, wird aber im Industrieumfeld in den meisten Fällen akzeptiert.
Die Netzwerkverbindung zwischen Webserver und den Endgeräten ist in diesem Szenario unbedingt zu Beginn zu klären. Gibt es Firewalls, die den Download der Anwendung verhindern?
Anwendungsfall 3: Steuerungsrechner
Eine Steuerungssoftware benötigt eine UI, um eine Maschine oder einen Prozess zu bedienen. Das Backend der Steuerungssoftware ist umfangreich, die UI hat je nach Anwendungsfall einen kleineren bis mittleren Umfang.
In diesem Szenario gibt es keine klare Empfehlung. Faktoren bei der Entscheidung sind:
- Zugriff auf lokale Ressourcen
- Lokaler oder verteilter Zugriff auf die UI
- Umfang der UI
Muss die UI zwingend auf lokale Ressourcen des Steuerungsrechners zugreifen, kommt man um Blazor Server kaum herum. Damit lassen sich diese Ressourcen einfach und schnell einbinden.
Ist kein direkter Zugriff auf lokale Ressourcen aus der UI nötig, ist die Art des UI-Zugriffs eine Entscheidungshilfe. Wird auf die UI vorrangig lokal vom Steuerungsrechner aus zugegriffen, erfüllt Blazor Server meist die Anforderungen. Wird verteilt auf die UI zugegriffen, zum Beispiel von mehreren Bedienstationen eines Leitstands aus, dann ist Blazor WebAssembly die bessere Wahl. Dann haben Netzwerklatenz und Auslastung des Steuerungsrechners keinen Einfluss auf die Reaktionszeit der UI.
Fällt die Wahl auf Blazor WebAssembly, ist wie in Anwendungsfall 2 das Netzwerk zu überprüfen.
Je umfangreicher die Funktionen der UI in einem verteilten Szenario, desto mehr sollte man neben Blazor WebAssembly auch die etablierten Frameworks wie Angular, React & Co in Betracht ziehen. Für umfangreiche UIs wird schnell ein eigenes Teammitglied benötigt, das sich ausschließlich darum kümmert. In diesen Fällen hängt die Wahl der Technologie auch davon ab, welche Kompetenzen die verfügbaren Mitarbeiter besitzen.
Fazit
In den meisten Fällen erfüllt Blazor sein zentrales Produktversprechen, es ist kein Knowhow in JavaScript erforderlich. Dadurch kann die UI auch durch Teams mit .NET-Hintergrund erstellt werden, die bisher noch nicht tief in die Webentwicklung eingestiegen sind.
Welche „Geschmacksrichtung“ von Blazor, welches Hosting-Modell gewählt wird, hängt vom Anwendungsfall ab. Exemplarisch wurden drei Anwendungsfälle aus der Industrie vorgestellt.
1 Microsoft hat die Probleme der Nutzer erhört und plant in .NET 8 ein anderes Format für die Assembly-Dateien anstatt von DLL. Details und Status: https://github.com/dotnet/runtime/issues/80807
Literatur
[1] Microsoft, „.NET Blog,“ 13 Juni 2023. [Online]. Available: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-5/. [Zugriff am 21 Juni 2023].
[2] Microsoft, „GitHub,“ 14 Februar 2023. [Online]. Available: https://github.com/dotnet/aspnetcore/issues/46636. [Zugriff am 21 Juni 2023].
Dieser Beitrag wurde verfasst von:
