Architekturvergleich zwischen ASP.NET Web Forms und Blazor

Tipp

Diese Inhalte sind ein Auszug aus dem eBook „Blazor for ASP NET Web Forms Developers for Azure“, verfügbar unter .NET Docs oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.

Blazor-for-ASP-NET-Web-Forms-Developers eBook cover thumbnail.

Während die Konzepte von ASP.NET Web Forms und Blazor viele Gemeinsamkeiten aufweisen, gibt es bei der Funktionsweise Unterschiede. In diesem Kapitel werden die interne Funktionsweise und Architektur von ASP.NET Web Forms und Blazor untersucht.

ASP.NET Web Forms

Das ASP.NET Web Forms-Framework beruht auf einer seitenbasierten Architektur. Jede HTTP-Anforderung für eine Position in der App stellt eine eigene Seite dar, auf die ASP.NET antwortet. Bei der Anforderung einer Seite wird der Browserinhalt durch die Ergebnisse der angeforderten Seite ersetzt.

Die Seiten umfassen die folgenden Komponenten:

  • HTML-Markup
  • C#- oder Visual Basic-Code
  • CodeBehind-Klasse mit Logik und Funktionen zur Ereignisbehandlung
  • Steuerelemente

Steuerelemente sind wiederverwendbare Elemente der Webbenutzeroberfläche, die programmgesteuert auf einer Seite platziert und mit denen interagiert werden kann. Die Seiten bestehen aus Dateien, die mit .aspx enden und die Markup, Steuerelemente und etwas Code enthalten. Die CodeBehind-Klassen befinden sich in Dateien mit demselben Basisnamen und (je nach verwendeter Programmiersprache) der Erweiterung .aspx.cs oder .aspx.vb. Der Inhalt von ASPX-Dateien wird vom Webserver interpretiert und bei jeder Änderung kompiliert. Diese Neukompilierung findet auch dann statt, wenn der Webserver bereits ausgeführt wird.

Steuerelemente können mit Markup erstellt und als Benutzersteuerelemente bereitgestellt werden. Ein Benutzersteuerelement wird von der UserControl-Klasse abgeleitet und verfügt über eine ähnliche Struktur wie die Seite. Markup für Benutzersteuerelemente wird in einer ASCX-Datei gespeichert. Die zugehörige CodeBehind-Klasse befindet sich in einer ASCX.CS- oder ASCX.VB-Datei. Steuerelemente können auch vollständig mit Code erstellt werden. Hierzu wird von der Basisklasse WebControl oder CompositeControl geerbt.

Die Seiten verfügen auch über einen umfangreichen Ereignislebenszyklus. Jede Seite löst Ereignisse für die Initialisierung sowie Load-, PreRender- und Unload-Ereignisse aus, die bei der Ausführung des Seitencodes durch die ASP.NET-Runtime für die einzelnen Anforderungen auftreten.

Die Steuerelemente auf einer Seite werden in der Regel an dieselbe Seite zurückgesendet, auf der sie angezeigt werden, und sie übertragen gleichzeitig Nutzdaten aus einem ausgeblendeten Formularfeld mit dem Namen ViewState. Das ViewState-Feld enthält Informationen über den Zustand der Steuerelemente zum Zeitpunkt des Renderings und der Anzeige auf der Seite. Dadurch können Änderungen am Inhalt, der an den Server gesendet wird, durch die ASP.NET-Runtime erkannt und verglichen werden.

Blazor

Blazor ist ein clientseitiges Framework für Webbenutzeroberflächen, das ähnlich wie die Front-End-Frameworks von JavaScript (z. B. Angular oder React) aufgebaut ist. Blazor verarbeitet Benutzerinteraktionen und rendert die erforderlichen Aktualisierungen der Benutzeroberfläche. Blazor basiert nicht auf einem Modell aus Anforderung und Antwort. Benutzerinteraktionen werden als Ereignisse behandelt, die nicht im Kontext einer bestimmten HTTP-Anforderung stehen.

Blazor-Apps bestehen aus einer oder mehreren Stammkomponenten, die auf einer HTML-Seite gerendert werden.

Blazor components in HTML

Die Art, wie Benutzer die Position von gerenderten Komponenten angeben können und wie diese anschließend für Benutzerinteraktionen miteinander verknüpft werden, hängt vom Hostingmodell ab.

Blazor-Komponenten sind .NET-Klassen, die ein wiederverwendbares Element der Benutzeroberfläche darstellen. Jede Komponente behält ihren Zustand bei und gibt ihre eigene Renderinglogik an, die auch das Rendern weiterer Komponenten beinhalten kann. Komponenten geben zur Aktualisierung des eigenen Status Ereignishandler für bestimmte Benutzerinteraktionen an.

Nach der Verarbeitung eines Ereignisses durch eine Komponente wird diese von Blazor gerendert, und es wird nachverfolgt, was sich in der gerenderten Ausgabe geändert hat. Komponenten werden nicht direkt in das Dokumentobjektmodell (DOM) gerendert. Sie werden vielmehr im Arbeitsspeicher in eine Darstellung des Dokumentobjektmodells mit dem Namen RenderTree gerendert. Auf diese Weise können Änderungen von Blazor nachverfolgt werden. Blazor vergleicht die neu gerenderte Ausgabe mit der vorherigen und berechnet einen Unterschied der Benutzeroberfläche, der anschließend auf effiziente Weise auf das DOM angewendet wird.

Blazor DOM interaction

Komponenten können auch manuell angeben, dass ein Rendering erforderlich ist, wenn sich ihr Status außerhalb eines regulären Benutzeroberflächenereignisses ändert. Blazor verwendet eine SynchronizationContext-Eigenschaft, um einen einzelnen logischen Ausführungsthread zu erzwingen. Die Lebenszyklusmethoden einer Komponente und alle Ereignisrückrufe, die von Blazor ausgelöst werden, werden in dieser SynchronizationContext-Eigenschaft ausgeführt.