Freigeben über


Eine Einführung in Blazor für ASP.NET Web Forms-Entwickler

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.

Das ASP.NET Web Forms-Framework ist seit der ersten Auslieferung von .NET Framework im Jahr 2002 ein Grundpfeiler der .NET-Webentwicklung. Als das Web noch weitgehend in den Kinderschuhen steckte, ermöglichte ASP.NET Web Forms eine einfache und produktive Entwicklung von Web-Apps, da viele der Muster übernommen wurden, die sich schon bei der Desktopentwicklung bewährt hatten. In ASP.NET Web Forms können Webseiten schnell aus wiederverwendbaren Benutzeroberflächen-Steuerelementen zusammengesetzt werden. Benutzerinteraktionen werden von Natur aus als Ereignisse behandelt. Es gibt ein sehr umfangreiches Ökosystem aus Benutzeroberflächen-Steuerelementen für Web Forms, die von Microsoft und anderen Anbietern von Steuerelementen bereitgestellt werden. Diese Steuerelemente vereinfachen Aufgaben wie das Herstellen einer Verbindung mit Datenquelle und das Anzeigen von umfangreichen Datenvisualisierungen. Für Benutzer, die am liebsten visuell arbeiten, bietet der Web Forms-Designer eine einfache Drag & Drop-Schnittstelle zur Verwaltung von Steuerelementen.

Im Lauf der Jahre hat Microsoft als Reaktion auf neue Trends bei der Webentwicklung neue, auf ASP.NET basierende Webframeworks eingeführt. Hierzu gehören beispielsweise ASP.NET MVC, ASP.NET Web Pages und seit jüngerer Zeit auch ASP.NET Core. Mit jedem neuen Framework wurde von bestimmten Kreisen der sofortige Niedergang von ASP.NET Web Forms vorhergesagt, und es wurde als antiquiertes, längst überholtes Framework geschmäht. Trotz dieser Unkenrufe betrachten viele .NET-Webentwickler ASP.NET Web Forms weiterhin als eine einfache, stabile und produktive Möglichkeit, ihre Arbeit zu erledigen.

Zum Zeitpunkt der Entstehung dieses Kapitels verwendeten fast eine halbe Million Webentwickler jeden Monat ASP.NET Web Forms. Das ASP.NET Web Forms-Framework ist so stabil, dass Dokumente, Beispiele, Bücher und Blogbeiträge von vor zehn Jahren immer noch nützlich und relevant sind. Für viele .NET-Webentwickler ist „ASP.NET“ immer noch gleichbedeutend mit „ASP.NET Web Forms“, wie bei der ersten Vorstellung von .NET. Über die Vor- und Nachteile von ASP.NET Web Forms im Vergleich zu den neueren .NET-Webframeworks mag nach wie vor hitzig gestritten werden – ASP.NET Web Forms ist und bleibt ein beliebtes Framework für das Erstellen von Web-Apps.

Gleichzeitig verlieren Innovationen in der Softwareentwicklung nichts an Tempo. Alle Softwareentwickler müssen bei neuen Technologien und Trends auf dem Laufenden bleiben. Zwei Trends sind besonders zu berücksichtigen:

  1. Die Verlagerung hin zu Open-Source- und plattformübergreifenden Anwendungen
  2. Die Verlagerung der App-Logik auf den Client

Ein plattformübergreifendes Open-Source-.NET

Als .NET und ASP.NET Web Forms veröffentlicht wurden, sah das Plattformökosystem völlig anders aus als heute. Die Märkte für Desktopcomputer und Server waren von Windows dominiert. Alternative Plattformen wie macOS und Linux hatten noch nicht richtig Fahrt aufgenommen. ASP.NET Web Forms wird als reine Windows-Komponente mit .NET Framework ausgeliefert. Das bedeutet, dass ASP.NET Web Forms-Apps nur auf Windows Server-Computern ausgeführt werden können. Viele moderne Umgebungen nutzen heute verschiedene Arten von Plattformen für Server und Entwicklungscomputer, sodass eine plattformübergreifende Unterstützung für viele Benutzer eine unabdingbare Voraussetzung ist.

Die meisten modernen Webframeworks basieren heute auf dem Open-Source-Prinzip, das eine Reihe von Vorteilen bietet. Benutzer sind nicht auf einen einzigen Projektbesitzer angewiesen, der Fehler behebt und Features hinzufügt. Open-Source-Projekte bieten mehr Transparenz in Sachen Entwicklungsfortschritt und bei anstehenden Änderungen. Open-Source-Projekte leben von den Beiträgen einer großen Community, und sie fördern ein unterstützendes Open-Source-Ökosystem. Angesichts der Risiken der Open-Source-Entwicklung haben viele Consumer und Mitwirkende geeignete Risikominderungen gefunden, die es ihnen ermöglichen, auf sichere und sinnvolle Weise von den Vorteilen eines Open-Source-Ökosystems zu profitieren. Beispiele für solche Risikominderungen sind Lizenzvereinbarungen für Mitwirkende, benutzerfreundliche Lizenzen, Herkunftsüberprüfungen und unterstützende Stiftungen.

Die .NET-Community hat sowohl die plattformübergreifende Unterstützung als auch die Open-Source-Entwicklung begrüßt. .NET Core ist eine plattformübergreifende Open-Source-Implementierung von .NET, die auf einer Vielzahl von Plattformen ausgeführt wird, einschließlich Windows, macOS und verschiedenen Linux-Distributionen. Xamarin stellt Mono bereit, eine Open-Source-Version von .NET. Mono wird unter Android und iOS sowie auf einer Reihe verschiedener Formfaktoren ausgeführt, wie z. B. Smartwatches und Smart-TVs. 2020 hat Microsoft .NET 5 herausgebracht. Diese Version vereint .NET Core und Mono zu „einer einzigen .NET-Runtime und einem einzigen Framework, die bzw. das überall verwendet werden kann und einheitliche Laufzeitverhalten und Entwicklerfunktionen bietet“.

Profitiert ASP.NET Web Forms von der Verlagerung hin zu plattformübergreifender Open-Source-Unterstützung? Die Antwort ist leider „Nein“, bzw. „nicht im selben Maß wie der Rest der Plattform“. Das .NET-Team hat erklärt, dass ASP.NET Web Forms nicht zu .NET Core oder .NET 8 portiert wird. Woran liegt das?

In der Anfangszeit von .NET gab es Bemühungen, ASP.NET Web Forms zu portieren. Allerdings stellte sich die Anzahl von erforderlichen Breaking Changes als deutlich zu hoch heraus. Es musste eingeräumt werden, dass es selbst für Microsoft eine Obergrenze in Bezug auf die Anzahl von Webframeworks gibt, die gleichzeitig unterstützt werden können. Möglicherweise findet sich in der Community jemand, der sich der Erstellung einer plattformübergreifenden Open-Source-Version von ASP.NET Web Forms annimmt. Der Quellcode für ASP.NET Web Forms wurde in Form einer Referenz öffentlich verfügbar gemacht. Bis dahin sieht es aber ganz so aus, als bliebe ASP.NET Web Forms eine reine Windows-Angelegenheit, ohne Open-Source-Beitragsmodell. Wenn plattformübergreifende Unterstützung oder Open-Source-Unterstützung für Ihre Szenarien wichtig wird, müssen Sie sich nach etwas Neuem umsehen.

Bedeutet das, dass ASP.NET Web Formsam Ende ist und nicht mehr verwendet werden sollte? Keinesfalls! Solange das .NET Framework zusammen mit Windows ausgeliefert wird, bleibt ASP.NET Web Forms ein unterstütztes Framework. Für viele Web Forms-Entwickler ist das Fehlen der plattformübergreifenden Open-Source-Unterstützung kein Problem. Wenn Sie keine plattformübergreifende Unterstützung, keine Open-Source-Unterstützung und keine anderen der neuen Features in .NET Core oder .NET 8 benötigen, können Sie ASP.NET Web Forms unter Windows selbstverständlich weiter verwenden. ASP.NET Web Forms wird noch viele Jahre lang eine produktive Möglichkeit sein, Web-Apps zu schreiben.

Es gibt jedoch einen weiteren Trend, den unter die Lupe zu nehmen sich lohnt: die Verlagerung hin zum Client.

Clientseitige Webentwicklung

Alle .NET-basierten Webframeworks – einschließlich ASP.NET Web Forms – hatten traditionellerweise einen gemeinsamen Aspekt: Sie werden vom Server gerendert. In vom Server gerenderten Apps sendet der Browser eine Anforderung an den Server, der Code ausführt (.NET-Code bei ASP.NET-Apps), um eine Antwort zu erzeugen. Diese Antwort wird zur Verarbeitung an den Browser zurückgesendet. In diesem Modell dient der Browser als Thin-Rendering-Engine. Die eigentliche Arbeit – Erzeugen der Benutzeroberfläche, Ausführen der Geschäftslogik und Verwalten des Zustands – erfolgt auf dem Server.

Browser haben sich jedoch zu vielseitigen Plattformen entwickelt. Sie implementieren immer mehr offene Webstandards, die Zugriff auf die Funktionen des Benutzercomputers ermöglichen. Warum also sollten Rechenleistung, Massenspeicher, Arbeitsspeicher und andere Ressourcen des Clientgeräts nicht nutzbringend eingesetzt werden? Insbesondere Benutzeroberflächeninteraktionen können von einer höheren Vielseitigkeit und Benutzerfreundlichkeit profitieren, wenn die Verarbeitung – teilweise oder sogar vollständig – auf Clientseite erfolgt. Logik und Daten, die auf dem Server verarbeitet werden sollen, können weiterhin auf dem Server verbleiben. Web-API-Aufrufe oder sogar Echtzeitprotokolle wie WebSockets können verwendet werden. Webentwickler können kostenlos von diesen Vorteilen profitieren, wenn sie gewillt sind, in JavaScript zu schreiben. Clientseitige Benutzeroberflächen-Frameworks wie Angular, React und Vue vereinfachen die clientseitige Webentwicklung und erfreuen sich immer größerer Beliebtheit. ASP.NET Web Forms-Entwickler können ebenfalls von der Nutzung des Clients profitieren und erhalten mit integrierten JavaScript-Frameworks wie ASP.NET AJAX sogar direkte Unterstützung.

Die Kombination zweier unterschiedlicher Plattformen und Ökosysteme (.NET und JavaScript) bringt aber auch Nachteile mit sich. Es ist Fachwissen in zwei Parallelwelten mit unterschiedlichen Sprachen, Frameworks und Tools erforderlich. Code und Logik lassen sich nicht ohne Weiteres zwischen Client und Server gemeinsam nutzen, was zu Duplizierung und Mehraufwand beim Engineering führt. Es ist auch nicht immer einfach, mit dem JavaScript-Ökosystem Schritt zu halten, das im Ruf steht, sich mit halsbrecherischer Geschwindigkeit zu entwickeln. Vorlieben für Front-End-Framework und Buildtools ändern sich schnell. Die Branche hat bereits den Wechsel von Grunt zu Gulp und dann zu webpack miterlebt. Eine ähnlich schnelle Abwanderung ließ sich bei Front-End-Frameworks wie jQuery, Knockout, Angular, React und Vue beobachten. Angesichts des Browsermonopols von JavaScript blieb allerdings kaum eine Wahl. Aber nur so lange, bis die Webcommunity sich zusammentat und ein wahres Wunder bewirkte!

WebAssembly erfüllt ein Bedürfnis

2015 schlossen sich die wichtigsten Browseranbieter in einer W3C-Communitygruppe zusammen, um einen neuen, offenen Webstandard namens WebAssembly zu schaffen. WebAssembly ist ein Bytecode für das Web. Wenn Sie Ihren Code für WebAssembly kompilieren können, kann er bei nahezu nativer Geschwindigkeit in jedem Browser auf jeder Plattform ausgeführt werden. Die ersten Bemühungen konzentrierten sich auf C/C++. Das Ergebnis war eine spektakuläre Demonstration, bei der native 3D-Grafik-Engines ohne Plug-Ins direkt im Browser ausgeführt wurden. Seitdem wurde WebAssembly standardisiert und von allen wichtigen Browsern implementiert.

Die Entwicklung der Ausführung von .NET in WebAssembly wurde Ende 2017 angekündigt, 2020 wurden die Ergebnisse veröffentlicht, einschließlich Unterstützung in .NET 5 und darüber hinaus. Die Fähigkeit, .NET-Code direkt im Browser auszuführen, ermöglicht die Webentwicklung des gesamten Stapels mit .NET.

Blazor: Webentwicklung für den gesamten Stapel mit .NET

Für sich allein genommen, bietet die Fähigkeit, .NET-Code in einem Browser auszuführen, keine End-to-End-Umgebung für die Erstellung von clientseitigen Web-Apps. An dieser Stelle tritt Blazor auf den Plan. Blazor ist ein clientseitiges Framework für Webbenutzeroberflächen, das auf C# anstelle von JavaScript basiert. Blazor kann über WebAssembly direkt im Browser ausgeführt werden. Es sind keine Browser-Plug-Ins erforderlich. Alternativ dazu können Blazor-Apps serverseitig in .NET ausgeführt werden und sämtliche Benutzerinteraktionen über eine Echtzeitverbindung mit dem Browser verarbeiten.

Blazor bietet eine ausgezeichnete Unterstützung für Tools in Visual Studio und Visual Studio Code. Das Framework umfasst auch ein vollständiges Modell für Benutzeroberflächenkomponenten sowie integrierte Funktionen für Folgendes:

  • Formulare und Überprüfung
  • Dependency Injection
  • Clientseitiges Routing
  • Layouts
  • Debuggen im Browser
  • JavaScript-Interoperabilität

Blazor hat viel mit ASP.NET Web Forms gemeinsam. Beide Frameworks bieten komponentenbasierte, ereignisgesteuerte, zustandsbehaftete Modelle für die Programmierung der Benutzeroberfläche. Der wesentliche Unterschied in der Architektur besteht darin, dass ASP.NET Web Forms nur auf dem Server ausgeführt wird. Blazor kann auch im Browser auf dem Client ausgeführt werden. Wenn Sie über ASP.NET Web Forms-Kenntnisse verfügen, wird Ihnen in Blazor vieles vertraut vorkommen. Blazor ist eine natürliche Lösung für ASP.NET Web Forms-Entwickler, die nach einer Möglichkeit suchen, von der clientseitigen Entwicklung und der plattformübergreifenden Open-Source-Zukunft von .NET zu profitieren.

Das vorliegende E-Book bietet eine Einführung in Blazor speziell für ASP.NET Web Forms-Entwickler. Jedes Blazor-Konzept wird im Kontext der entsprechenden ASP.NET Web Forms-Features und -Methoden vorgestellt. Am Ende dieses E-Books verfügen Sie über folgende Kenntnisse:

  • Erstellen von Blazor-Apps
  • Funktionsweise von Blazor
  • Beziehung von Blazor zu .NET
  • Vernünftige Strategien für das Migrieren von ASP.NET Web Forms-Apps zu Blazor, wo sinnvoll

Erste Schritte mit Blazor

Der Einstieg in Blazor ist ganz einfach. Wechseln Sie zu https://blazor.net, und folgen Sie den Links, um das geeignete .NET SDK und Blazor-Projektvorlagen zu installieren. Sie finden dort auch Anweisungen zum Einrichten der Blazor-Tools in Visual Studio oder Visual Studio Code.