Blazor-Entwicklung: Komponenten, die immer passen

Inhaltsverzeichnis

Entwickler und Entwicklerinnen können mithilfe einer Razor Class Library gemeinsame Razor Components zwischen allen vier Blazor-Varianten (Blazor WebAssembly, Blazor Server, Blazor Desktop und Blazor MAUI) einsetzen, wie schon der Artikel "Eine Blazor-App für alle Plattformen“ gezeigt hat.

Blazor-Arten im Architekturvergleich

Zu den Unterschieden zwischen den vier Blazor-Arten gehört auch, dass sie verschiedene Schichtenarchitekturen (Bild 1 und 2) ermöglichen:

• Eine Blazor-WebAssembly-Anwendung ist immer eine 3-Tier-Anwendung, denn sie läuft in der Sandbox des Webbrowsers, die nur einen Zugriff auf HTTP(S)-basierte Webservices (unter anderem REST-APIs, andere WebAPIs, gRPC-Dienste oder SignalR-Dienste) erlaubt.
• Bei einer Blazor-Server-Anwendung läuft der C#-Programmcode hingegen auf dem Webserver ohne Sandbox. Von hier aus können Entwickler und Entwicklerinnen direkt beliebige Ressourcen wie Datenbankmanagementsysteme ansprechen, sofern sie vom Webserver aus erreichbar sind. Ein Zugriff auf Webservices ist auch möglich; sodass die Wahl zwischen 2-Tier- und 3-Tier-Architekturen besteht.
• Blazor-Desktop-Anwendungen laufen ohne Sandbox direkt im Benutzerkontext von Windows. Sie können ist auf alle Ressourcen zugreifen, die für den angemeldeten Benutzer erreichbar sind. Auch hier haben Entwickler die Wahl zwischen 2-Tier- und 3-Tier-Architekturen.
• Blazor MAUI läuft ebenfalls nicht in einer Sandbox. Allerdings sind auf den Mobilbetriebssystemen in der Regel keine Datenbanktreiber vorhanden. Üblich ist daher eine 3-Tier-Architektur; 2-Tier ist auf Mobilplattformen verpönt.

Gemeinsamkeit nur über Webservices?

Wer eine Blazor-Anwendung schreiben will, die in einer Razor Class Library läuft und von allen Blazor-Arten eingebunden werden kann (via Kopf-Projekten, siehe "Eine Blazor-App für alle Plattformen“), muss den Zugriff auf die benötigten Ressourcen in allen Blazor-Arten ermöglichen. Ein erster Gedanke: Der gemeinsame Nenner zwischen allen Blazor-Arten ist eine 3-Tier-Anwendung. Wenn also Razor Components in der Razor Class Library immer per Webservice auf die Datenbank zugreifen, laufen sie in allen Blazor-Arten.

Das stimmt, ist aber die einzige Option. Wer in Blazor Server und Blazor Desktop mit Webservices auf einem Application Server arbeitet, obwohl er das Datenbankmanagementsystem auch direkt ansprechen könnte, handelt sich zusätzlichen Netzwerkverkehr ein, der die Anwendung zunächst verlangsamt. Ein Application Server kann dies gegebenenfalls durch gutes Caching wieder ausgleichen.

Hier soll aber ein Ansatz präsentiert werden, bei dem Blazor Server und Blazor Desktop die Datenbank direkt verwenden, während Blazor WebAssembly und Blazor MAUI per Webservice auf die gleiche Datenbank zugreifen. Dabei verwenden alle vier Blazor-Arten die gleichen Razor Components in einer gemeinsamen Razor Class Library.

Entwickler können dafür den Datenzugriff komplett in die Kopfprojekte verlagern und die Razor Components in der Razor Class Library auf das Rendering reduzieren. In diesem Beispiel können die Razor Components in der Razor Class Library Daten abrufen und speichern. Dazu wird eine Abstraktionsschicht für den Datenzugriff zwischen 2-Tier und 3-Tier eingezogen, die mit einem Trick sehr effizient ist.