Architekturvergleich von ASP.NET Webformularen 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.

PDF herunterladen

Obwohl ASP.NET Web Forms und Blazor viele ähnliche Konzepte teilen, gibt es Unterschiede in ihrer Funktionsweise. In diesem Kapitel werden die Funktionsweise und Architekturen von ASP.NET Web Forms und Blazor untersucht.

ASP.NET Webformulare

Das ASP.NET Web Forms Framework basiert auf einer seitenorientierten Architektur. Jede HTTP-Anforderung für einen Speicherort in der App ist eine separate Seite, mit der ASP.NET antwortet. Wenn Seiten angefordert werden, werden die Inhalte des Browsers durch die Ergebnisse der angeforderten Seite ersetzt.

Seiten bestehen aus den folgenden Komponenten:

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

Steuerelemente sind wiederverwendbare Einheiten der Web-UI, die programmgesteuert auf einer Seite platziert und interagiert werden können. Seiten bestehen aus Dateien, die mit .aspx enden , die Markup, Steuerelemente und code enthalten. Die CodeBehind-Klassen befinden sich in Dateien mit demselben Basisnamen und einer .aspx.cs - oder .aspx.vb-Erweiterung , je nach verwendeter Programmiersprache. Interessanterweise interpretiert der Webserver Inhalte der .aspx Dateien und kompiliert sie, wenn sie sich ändern. Diese Neukompilierung tritt auch dann auf, 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 hat eine ähnliche Struktur wie die Seite. Markup für Benutzersteuerelemente wird in einer ASCX-Datei gespeichert. Eine zugehörige CodeBehind-Klasse befindet sich in einer .ascx.cs - oder .ascx.vb Datei. Steuerelemente können auch vollständig mit Code erstellt werden, indem sie entweder von der WebControl oder CompositeControl Basisklasse erben.

Seiten haben auch einen umfangreichen Ereignislebenszyklus. Jede Seite löst Ereignisse für initialisierungs-, load-, prerender- und unload-Ereignisse aus, die auftreten, während die ASP.NET Laufzeit den Code der Seite für jede Anforderung ausführt.

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 zum Zustand der Steuerelemente zum Zeitpunkt des Renderns und Präsentierens auf der Seite, sodass die ASP.NET Laufzeit Änderungen des an den Server übermittelten Inhalts vergleichen und identifizieren kann.

Blazor

Blazor ist ein clientseitiges Web-UI-Framework ähnlich wie JavaScript-Front-End-Frameworks wie Angular oder React. Blazor behandelt Benutzerinteraktionen und rendert die erforderlichen UI-Updates. Blazor basiert nicht auf einem Anforderungsantwortmodell. Benutzerinteraktionen werden als Ereignisse behandelt, die sich nicht im Kontext einer bestimmten HTTP-Anforderung befinden.

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

Wie der Benutzer angibt, wo Komponenten gerendert werden sollen und wie die Komponenten dann für Benutzerinteraktionen verkabelt werden sollen, ist das Hostmodell spezifisch.

Blazor Komponenten sind .NET-Klassen, die ein wiederverwendbares Ui-Element darstellen. Jede Komponente behält ihren eigenen Zustand bei und gibt eine eigene Renderinglogik an, die das Rendern anderer Komponenten umfassen kann. Komponenten geben Ereignishandler für bestimmte Benutzerinteraktionen an, um den Zustand der Komponente zu aktualisieren.

Nachdem eine Komponente ein Ereignis verarbeitet hat, Blazor rendert die Komponente und verfolgt, was sich in der gerenderten Ausgabe geändert hat. Komponenten werden nicht direkt im DOM (Document Object Model) 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 Ausgabe, um einen UI-Diff zu berechnen, der dann effizient auf das DOM angewendet wird.

Komponenten können auch manuell angeben, dass sie gerendert werden sollen, wenn sich ihr Zustand außerhalb eines normalen UI-Ereignisses ändert. Blazor verwendet einen SynchronizationContext, um einen einzigen logischen Ausführungsthread sicherzustellen. Die Lebenszyklusmethoden einer Komponente und alle Ereignisrückrufe, die von Blazor dieser komponente ausgelöst werden, werden auf diese SynchronizationContextWeise ausgeführt.

ZurückWeiter