Mit .NET ins Web

Noch immer gibt es eine gewisse Spaltung im Lager der Softwareentwickler. Die einen bauen Desktop-Applika­tionen und schwören auf native Apps, die auf den Endgeräten direkt und ohne Umweg über den Browser ausgeführt werden. Andere Entwickler erstellen Webapplikationen, heute oft in Form einer Single-Page-Applikation (SPA). So unterschiedlich, wie diese beiden Typen von Anwendungen sind, so heterogen sind auch die Abläufe, Programmiersprachen und Werkzeuge für die Programmierung. Die Entwicklung von Desktop-Applikationen erfolgt in der Regel in umfassenden integrierten Entwicklungsumgebungen, typische Programmiersprachen sind Java, C# et cetera. Das User Interface wird oft deklarativ und oder mit Unterstützung eines grafischen Designers erstellt. Ganz anders Webapplikationen: Technologisch haben wir eigentlich nur HTML (Struktur), CSS (Layout, Design) und JavaScript (Logik, Interaktion). Schwergewichtiger ist hier vielmehr die Entscheidung, welche Teile einer Applikation auf dem Client und welche auf dem Server ausgeführt werden. Wir können hier grob zwischen den traditionellen Webapplikationen und den Formen einer SPA unterscheiden [1] (Bild 1). Das entscheidende Merkmal besteht also darin, dass bei der ersten Variante bei der Aktualisierung der View, zum Beispiel bei der Neuanzeige von Daten, diese komplett ausgetauscht wird. Eine SPA geht hier mit Fingerspitzengefühl vor, es werden also nur diejenigen Teile der Seite (Elemente, Widgets) aktualisiert, die von der Änderung betroffen sind (Bild 2). Die SPA kann daher mit einigen Vorteilen punkten:

Diese Vorteile einer SPA sind jedoch auch nicht umsonst zu haben. Es braucht dafür eine gut durchdachte Anwendungsarchitektur.

Genau an dieser Stelle kommen Bibliotheken und Frameworks zum Einsatz, um für die Webapplikation eine Struktur vorzugeben beziehungsweise die Arbeit mit stetig wiederkehrenden Aufgaben zu erleichtern und zu standardisieren. Dazu gehören zum Beispiel Frameworks wie Angular.js oder React.js. Hier gibt es eine reiche Auswahl an Bibliotheken und Frameworks, die man darüber hinaus gefühlt alle miteinander kombinieren kann.

Auch das Tooling zum Erstellen einer solchen SPA unterscheidet sich in vielen Punkten vom Vorgehen bei der Programmierung von nativen Applikationen. Statt in einer alles umfassenden integrierten Entwicklungsumgebung mit einem „schützenden“ Designer wird in einem Editor mit Plug-ins und Extensions eigener Wahl und der Interaktion auf der Kommandozeile forsch drauflosprogrammiert. Die einen lieben diese Vielfalt und Flexibilität, andere Entwickler – auch Umsteiger – sehnen sich vielleicht auch danach, etwas mehr Struktur in den Entwicklungszyklus zu bekommen. Insbesondere das Dreiergespann aus HTML, CSS und JavaScript ist nicht jedermanns Sache, denn es fokussiert sehr stark auf die technischen Belange und lenkt schnell vom Fokus der App ab.

Relativ neue Ansätze sind Blazor Server und Blazor Web­Assembly [2][3]. Beide Technologien basieren auf Microsoft
.NET und man programmiert mit C#. Damit dürfte die Zielgruppe von Blazor klar sein: Entwickler mit Erfahrungen in .NET und C# sollen sich hier schneller als in der klassischen Webwelt zu Hause fühlen und in der Lage sein, moderne SPAs zu erstellen. Das ist unser Thema für die mit diesem Artikel beginnende Serie: eine systematische Einführung mit Hintergründen und einen ersten Einblick in die Programmierpraxis zu geben, siehe Kasten Web-Apps mit Blazor. Am Ende sollte der Leser in der Lage sein, erste moderne Web­applikationen mit Blazor zu erstellen. Gelingt dies, dann erweitern wir die Reichweite der von uns eingesetzten Technologie erheblich. Wir können dann mit .NET und C# nicht nur nativ auf dem Desktop (UWP, Win UI, WPF, Win Forms) und mobil (Xamarin) punkten, sondern erreichen auch das Web.

Bei Blazor handelt es sich um ein Open-Source-Framework von Microsoft. Es verwendet wie andere Webframeworks ­HTML und CSS zur Darstellung. Ein Unterschied besteht jedoch darin, dass die Logik nicht mit JavaScript, sondern mit C# und der Razor-Syntax ausgeführt wird. Bevor wir also konkret einsteigen können, müssen wir diese technischen Hintergründe aufklären. Die Basis für den neuen Ansatz ist die WebAssembly-Technologie (Wasm) [4]. WebAssembly ist ein binäres Befehlsformat für die virtuelle Maschine im Browser. Es wurde als portables Kompilierungsziel für Programmiersprachen entwickelt und ermöglicht die Bereitstellung im Web für Client- und Serveranwendungen. Ziel der Entwicklung ist eine Ergänzung von performanten Funktionen zu JavaScript, sowohl was die Ladezeiten als auch die Ausführung betrifft. Das Projekt wird von allen großen Entwicklern der Browser-Engines, also Mozilla, Microsoft, Google und Apple, betrieben. Was sind die Gründe für diesen neuen Standard? WebAssembly bietet zwei Hauptvorteile:

Natürlich bringt jeder neue Standard auch die Notwendigkeit von Anpassungen mit sich, dennoch geht man davon aus, dass langfristig die Vorteile die Nachteile übersteigen. Die Unterschiede in der Technologie sind für eine klassische Java­Script- und eine auf WebAssembly basierende Webapplikation in Bild 3 gegenübergestellt [5]. Vor der Nutzung von WebAssembly wurde der JavaScript-Code durch den Client (Browser) vom Server geladen, analysiert (Parser, Compiler) und dann ausgeführt. Mit der WebAssembly-Technologie kompiliert der Server den Code in Wasm (WebAssembly). Dieser wird dann direkt vom Just-in-Time (JIT)-Compiler des Browsers ausgeführt. Damit ist WebAssembly ein binäres Format, das für die Ausführung im Browser optimiert ist, und kein JavaScript-Code.

WebAssembly bietet zusammengefasst die folgenden Merkmale (Vorteile):

WebAssembly ist eine technische Basis für Blazor. Die andere Basis ist Razor. Es gilt: Browser + Razor = Blazor. Um hier also weiterzukommen, müssen wir den Ansatz von Razor zumindest fundamental erklären und verstehen.

Razor ist eine Markup-Syntax zum Einbetten von Code (hier C#) in HTML. Razor verwendet das @-Symbol für den Übergang von HTML zu C#. Dabei werden die C#-Ausdrücke ausgewertet und zur HTML-Ausgabe verarbeitet. Man unterscheidet implizite und explizite Razor-Ausdrücke. Ein impliziter Ausdruck beginnt mit @ und es folgt der C#-Code, also zum Beispiel:

<p>@DateTime.Now</p> 

In diesem Fall erfolgt also die Ausgabe des aktuellen Datums innerhalb des Absatzes (<p/>). Implizite Ausdrücke dürfen keine Leerzeichen und keine Generics enthalten. Hier sind dann explizite Ausdrücke zu verwenden.

Explizite Ausdrücke beginnen ebenfalls mit einem @-Zeichen, danach folgt eine öffnende Klammer, dann folgt der C#-Quellcode und wiederum eine schließende Klammer, also in der Form @(…). Ein Beispiel:

<p>Last week this time: @(DateTime.Now - 
  TimeSpan.FromDays(7))</p> 

Jeglicher Code innerhalb von @(…) wird ausgewertet und in die Ausgabe gerendert.

Neben Ausdrücken können wir auch Codeblöcke definieren. Razor-Codeblöcke beginnen mit @ und werden von {…} eingeschlossen. Hier erfolgt kein Rendering, sondern es wird Logik definiert. Ein Beispiel:

@{ 
  void PrintName(string name) 
  { 
    <p>Name: <strong>@name</strong></p> 
  } 

  PrintName("Klaus Müller"); 
} 

Wir definieren eine lokale Funktion in C# namens PrintName(…) mit dem Parameter name und dem Datentyp string. Diese Funktion gibt die Zeichenkette name innerhalb eines <p\>-Tags aus. Die Funktion können wir mit einem Wert des Parameters aufrufen. Im Ergebnis bekommen wir folgenden HTML-Code:

<p>Name: <strong>Klaus Müller</strong></p> 

Flexibel wird das „Mischen“ von HTML und C# durch die Möglichkeit, Auswahlentscheidungen, Schleifen, Fehlerbehandlung und mehr nutzen zu können. Dazu noch ein kleines Beispiel (Listing 1): Wir definieren zunächst eine Liste von Objekten mit dem Datentyp Person, das heißt, die Klasse Person sollte schon existieren. Im nächsten Schritt iterieren wir über jedes Objekt der Liste mithilfe der Foreach-Schleife. Der Quellcode ist selbsterklärend und entspricht dem Vorgehen in C#. Die Razor-Syntax holt also die Sprachmerkmale von C# in den HTML-Code und macht diesen damit dynamisch.

Die weiteren Sprachmerkmale funktionieren ähnlich. Einen kompakten Überblick über die Razor-Syntax bekommen Sie beispielsweise in der Dokumentation unter [6].

Wenn Sie (noch) keine Erfahrungen mit Razor gesammelt haben, so ist das an dieser Stelle kein Problem. Bei der Entwicklung mit Blazor benötigen wir zwar diese Syntax, aber wir können sie durchaus dann implizit mit erlernen, wenn wir erste Blazor-Komponenten erstellen. Weiter geht es daher mit Blazor.

Blazor gibt es in mehreren Ausführungsvarianten [2] [7]:

Sehen wir uns diese einzelnen Spielarten für Blazor-basierte Apps genauer an.

Die Funktionsweise von Blazor Server ist in Bild 4 zu sehen [7]. Die Arbeitsweise ist der von ASP.NET MVC und ASP.NET Razor Pages ähnlich, jedoch wird auf dem Server eine SPA gerändert und diese wird an den Client ausgeliefert. Zum Client werden JavaScript und Markup gesendet und die Daten und Benutzereingaben werden laufend mittels der Bibliothek SignalR zwischen Client und Server ausgetauscht, vergleiche den Kasten SignalR.

Das Blazor-Server-Hostingmodell besitzt folgende Vorteile:

Wie immer gibt es auch ein paar Einschränkungen:

Kommen wir zu Blazor WebAssembly. Wir sehen die Architektur in Bild 5 [7]. Blazor WebAssembly läuft auf dem Client (siehe obige Ausführungen zum Thema WebAssembly). Die Blazor-App, die jeweiligen Abhängigkeiten und die .NET-Runtime werden vom Browser heruntergeladen. Diese App wird direkt im Thread des User Interface des Browsers ausgeführt. Der Zugriff auf Kamera, Mikrofon und andere Komponenten des Clients ist ohne JavaScript über Blazor Component möglich. Gibt es diese nicht, dann kann über eine Java­Script-Interoperation mittels JavaScript zugegriffen werden. Der Webserver muss lediglich das Static File Deployment unterstützen, um eine Blazor WebAssembly zu hosten. Da der gesamte Code direkt im Client läuft, kann die Applikation gut skalieren. Lediglich der initiale Download ist groß, was zu einer längeren Startzeit führt. Danach läuft die App performant. Tabelle 1 vergleicht die beiden Ansätze von Blazor Server und Blazor WebAssembly anhand wesentlicher Merkmale miteinander.

Kommen wir zu den beiden weiteren Blazor-App-Typen. Mit Blazor Mobile Bindings soll das App-Modell speziell für Mobile Devices zugänglich gemacht werden [8]. Das Ziel besteht darin, dass Erstellen von nativen und hybriden Apps mit C# und .NET für Android und iOS unter Verwendung bekannter Web-Programmiermuster zu ermöglichen. Blazor Mobile Bindings verwendet die Razor-Syntax, um User-Interface-Komponenten und das Verhalten der App zu definieren. Die zugrunde liegenden Komponenten basieren auf nativen UI-Komponenten von Xamarin.Forms und werden in Hybrid-Apps mit HTML-Elementen gemischt. Das Ganze hat noch experimentellen Status.

Ebenfalls noch in der Phase des Probierens ist der Ansatz, eine App auf der Basis von Blazor mithilfe von Electron auf dem Desktop lauffähig zu machen. Informationen dazu finden Sie zum Beispiel unter [9] oder [10].

Wie geht es jetzt hier weiter? Wir verschaffen uns zunächst einen allgemeinen Überblick über Blazor und den zugrunde liegenden komponentenbasierten Ansatz. Danach geht es um die Installation, die Einrichtung und das Tooling, um mit dem Blazor-Framework eine App zu erstellen. Unseren ersten Teil der Serie schließen wir mit den klassischen „Hello World“-Apps ab, um einen ersten Eindruck vom Entwicklungszyklus mit Blazor zu bekommen.

Sehen wir uns das Framework Blazor genauer an. Das Ziel sind also moderne clientseitige Webapplikationen. Dabei haben wir es mit den folgenden Kerneigenschaften zu tun:

Blazor basiert auf einem komponentenbasierten Ansatz. Eine Komponente ist zum Beispiel eine Seite, ein Dialogfeld, ein Formular und so weiter. Zugrunde liegt ein Ereignismodell, um auf Benutzerinteraktionen zu reagieren.

Die gesamte App besteht aus einer oder mehreren Stammkomponenten, die auf der initialen HTML-­Seite eingebunden werden (Bild 6) [11]. Eine Komponente ist eine
.NET-Klasse, hat einen Zustand und Logik zum Rendern. Eine Komponente kann Benutzerinteraktionen verarbeiten und dann den Status aktualisieren. Beim Rendering erfolgt ein Abgleich zwischen den DOM-Modell der Seite und einer internen Repräsentation des DOM-Modells in Blazor. Dabei werden die notwendigen Änderungen aus der Differenz der zwei Zustände bestimmt und die Änderungen umgesetzt (Bild 7) [11]. Ein manuelles Anstoßen eines Renderings einer Komponente ist möglich.

Eine Komponentenklasse hat die Dateierweiterung *.razor. In einer solchen Datei werden HTML-­Markup und C#-Quellcode miteinander kombiniert ­(siehe oben). Durch das Tooling der Entwicklungsumgebung wird diese Besonderheit mit IntelliSense bei der Codierung unterstützt.

Der Blick in den „gemischten“ Quellcode (Listing 2) lässt uns den Aufbau einer Komponente er­kennen. Es handelt sich um eine einfache Zählerkomponente. Im HTML-­Teil wird das User Interface definiert. Das geschieht mit den normalen HTML-Tags (<h1\>, <p\>, <button\>). Im C#-Teil findet sich üblicher C#-Code. Im Beispiel werden beide Teile über ein Ereignis (@onclick) und die lokale Variable (currentCount) miteinander verbunden. Damit wird auch eine Aktualisierung des User Interface als Reaktion auf die Benutzerinteraktion erreicht.

Installation und Tooling sind weitgehend flexibel und lassen sich mit überschaubarem Aufwand einrichten. Was die Entwicklungsumgebung angeht, haben wir je nach Betriebssystem die Wahl:

Beachten Sie dabei noch die folgenden Hinweise. Beginnen wir mit Visual Studio 2019. Spielen Sie in diesem Zusammenhang die gegebenenfalls noch ausstehenden Updates ein. Ebenso installieren Sie den Workload ASP.NET und Webent­wicklung über den Visual Studio Installer (Bild 8).

Wenn Sie unter macOS arbeiten, können Sie Visual Studio für Mac verwenden. In diesem Fall gilt: Ab Version Visual Studio für Mac 8.6 werden beide Hosting-Modelle, also sowohl Blazor WebAssembly als auch Blazor Server, unterstützt (Bild 9)

Arbeiten Sie mit einer der beiden Visual-Studio-Versionen, sind Sie gleich bereit für Ihre Blazor-App. Kommen wir zu Visual Studio Code. Aktualisieren Sie auch hier auf die neueste Version. Dieser Editor ist bekanntlich flexibel anpassbar und betriebssystemneutral. Wir müssen die aktuelle Version des .NET Core SDK installieren [12]. Prüfen Sie mit der Eingabe von

dotnet –version 

auf der Kommandozeile die Aktualität des SDK. Installieren Sie die Erweiterung C# for Visual Studio Code [13] für eine Unterstützung der Programmiersprache C#. Ebenso ist es sinnvoll, die Erweiterung JavaScript-Debugger zu installieren und diese zu aktivieren (Bild 10). Damit ist die Einrichtung abgeschlossen.

Arbeitet man mit Visual Studio Code, wird das Projektskelett auf Ebene der Kommandozeile angelegt. Dazu kommen wir gleich noch einmal.

Wir wollen im Folgenden davon ausgehen, dass wir unter dem „großen“ Visual Studio arbeiten.

Los geht es. Starten wir Visual Studio 2019 und erstellen wir ein neues Projekt des Typs Blazor App(Bild 11). Als Nächstes werden wir aufgefordert, das Hosting-Modell zu wählen (Bild 12). In diesem Fall entscheiden wir uns für Blazor WebAssembly. Danach erstellt Visual Studio die App mit einigen Beispielkomponenten und konfiguriert diese entsprechend, das heißt, dass unter anderem IIS Express als lokaler Webserver eingerichtet wird.

Sind wir einmal so weit gekommen, juckt es uns in den Fingern, auf Ausführen zu klicken. Das machen wir auch und starten die App direkt aus Visual Studio heraus. Darüber hinaus wird noch die eine oder andere Berechtigung angefordert und die App im Browser (Edge) gestartet. Der Server lauscht dabei auf der lokalen Adresse https://localhost auf dem Port 44339.

Die Beispiel-App umfasst drei Komponenten, die in Form von Pages dargestellt werden; konkret sind dies eine statische Seite (Home), eine Seite mit Interaktion (Button mit Klick-Funktion) und eine Seite mit einer tabellarischen Darstellung (Grid) (Bild 13).

Als Voraussetzung für den weiteren Einstieg studieren wir zunächst die generierte Projektstruktur der Blazor-Web­Assembly-App (vergleiche Tabelle 2). Anschließend kommen wir zum Hosting-Modell Blazor Server.

Durchlaufen wir nun den Vorgang zum Erstellen der Blazor-App für das Hosting-Modell auf dem Server. Auch mit dieser Vorlage wird das Anwendungsgerüst erstellt und eine startfähige App generiert.

Nach dem Build und dem Start der App sehen wir gegenüber dem Anwendungsmodell Blazor WebAssembly keinen Unterschied. Dieser findet sich ausschließlich unter der Haube, nämlich in der in Tabelle 2 vorgestellten Aufteilung der Aufgaben zwischen Client (Browser) und dem Server. Einige Unterschiede gibt es in der Dateistruktur.

Mit diesen beiden App-Modellen haben wir den Anfang geschafft und können uns dann konkreten und typischen Aufgaben der App-Entwicklung zuwenden.

In diesem ersten Teil der Artikelserie haben wir Blazor in die Welt der modernen Webprogrammierung eingeordnet. Programmieransatz und Tooling richten sich klar an Entwickler mit Kenntnissen aus dem .NET-Umfeld.

Auch die Nutzung von WebAssembly scheint ein gang­barer Weg zu sein, da hier keine herstellerspezifischen Plug-ins benötigt werden, sondern es auf einem Webstandard aufsetzt. Auch wenn dieser zugegebenermaßen noch neu ist, macht es einen erheblichen Unterschied.

Im nächsten Teil der Serie zu Blazor wenden wir uns den Basics zu, die wir zum Erstellen von Blazor-basierten Apps benötigen. Das sind beispielsweise das Erstellen von Komponenten, das Routing, die Datenbindung und das Behandeln von Ereignissen. Wenn wir das alles zusammenhaben, sind wir so weit, uns an etwas größere Projekte zu wagen.