Umstieg auf .NET Core: ASP.NET-Webserveranwendungen umstellen

Im dritten von fünf Beiträgen zur Migration vom klassischen .NET Framework auf .Net Core, geht es um die Umstellung ASP.NET-basierter Webserveranwendungen.

Lesezeit: 10 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 9 Beiträge

(Bild: Andrey Suslov/Shutterstock.com)

Von
Inhaltsverzeichnis

.NET Core unterstützt in Form von ASP.NET Core seit seiner ersten Version im Jahr 2016 die Entwicklung von Webanwendungen mit serverseitigem HTML-Rendering (alias Multi-Page Web Applications – MPA) genau wie das Erstellen von HTTP-Webservices nach dem REST-Prinzip. Neu seit ASP.NET Core 3.0 ist auch die Unterstützung für Single-Page Web Applications (SPA). In diesem Beitrag geht es um MPAs und SPAs, ein genauerer Blick auf die Webservices folgt im vierten Teil der Beitragsserie.

Zunächst einmal ist das Verständnis wichtig, dass ASP.NET und ASP.NET Core kein einheitliches Webserverframework sind, sondern eine Sammlung verschiedener Webframeworks mit verschiedenen Softwarearchitekturen. Im alten ASP.NET im klassischen .NET Framework finden sich sieben Varianten für MPAs und Webservices:

  1. ASP.NET Webforms ist das ursprüngliche Architekturmodell in ASP.NET auf Basis von Webserver-Steuerelementen in .aspx-Dateien, die HTML, CSS und JavaScript generieren. Wahlweise kann der C#- oder Visual-Basic-.NET-Programmcode in der .aspx-Datei oder einer Code-Behind-Datei (.aspx.cs oder .aspx.vb) enthalten sein. Mit dem in die Seiten hineingerenderten versteckten Feld namens "ViewState" lässt sich ein Seitenzustand zwischen zwei HTTP-Anfragen festhalten. JavaScript kommt bei diesem Architekturmodell nur in geringen Dosen zum Einsatz. Entwickler haben beim Verwenden der Webserver-Steuerelemente nur begrenzten Einfluss auf die HTML-Ausgabe. Vorteil des Modells ist aber seine hohe Produktivität.
  2. ASP.NET AJAX, eine Erweiterung zu Webforms, verschafft mehr Möglichkeiten zur clientseitigen Ausführung im Browser mit JavaScript. Dazu bietet ASP.NET AJAX einige Steuerelemente, die mit viel JavaScript im Browser laufen.
  3. ASP.NET-Dynamic-Data-Websites sind ein metadatengetriebener Ansatz zum automatischen Generieren von Weboberflächen für die Datenansicht und Dateneingabe, vergleichbar mit Ruby-on-Rails. ASP.NET Dynamic Data wurde mit .NET 3.5 Service Pack 1 eingeführt und in .NET 4.0 erweitert.
  4. ASP.NET Model View Controller (MVC) ist seit 2009 das wichtigste Architekturmodell. Der Controller (.cs-Programmcodedatei) auf dem Server füttert den MVC-View mit Daten. Der View (.cshtml) erzeugt aus einer Template-Syntax mit einer wählbaren View Engine (Microsoft liefert ASPX-Syntax <span><%=x%></span> und die Razor-Syntax <span>@x</span>) eine HTML-Seite, die als Ganzes zum Webbrowser übertragen wird. ASP.NET MVC bietet gegenüber den vorgenannten Modellen eine bessere Kompetenztrennung in der Benutzerschnittstelle, eine bessere Kontrolle über die HTML-Ausgabe, eine bessere Integrierbarkeit von JavaScript sowie bessere Testbarkeit. MVC ist aber weniger produktiv als das Webforms-Modell, weil es hier keine Abstraktion durch Webserver-Steuerelemente und ViewState gibt.
  5. ASP.NET Web Pages basieren auch auf der Razor-Syntax, verflechten aber Programmcode und HTML/CSS in einer Datei (.cshtml). Es gibt einen zugehörigen Editor Webmatrix. ASP.NET Webpages und Webmatrix richten sich eher an Gelegenheits- und Hobby-Programmierer. Microsoft zielte mit dieser Variante auf Entwickler, die PHP mögen. In Deutschland hatte dieses Architekturmodell nur geringe Bedeutung.
  6. SOAP-basierte Webservices kann man in ASP.NET seit der Version 1.0 mit ASP.NET Webservices (alias: ASMX, basierend auf der verwendeten Dateinamenserweiterung .asmx) erstellen. Das Architekturmodell gilt jedoch als veraltet, seit .NET Framework 3.0 im Jahr 2006 die Windows Communication Foundation (WCF) eingeführt hat.
  7. REST-basierte Webservices erlaubt ASP.NET WebAPI, das es seit dem Jahr 2012 gibt.

Diese sieben Architekturmodelle lassen sich auch in einem Webprojekt mischen, weil es in ASP.NET einen gemeinsamen Unterbau gibt.

Im neuen ASP.NET Core gibt es auf dem heutigen Stand nur noch fünf Architekturmodelle (siehe Abb. 1):

  1. Ganz oben sieht man die Model-View-Controller-Architektur (MVC), die seit Version 1.0 (Jahr 2016) in ASP.NET Core existiert. Allerdings ist die ASPX-Syntax mit <span><%=x%></span> nicht mehr möglich, sondern nur noch die Razor View Engine mit <span>@x</span>.
  2. Seit ASP.NET Core 2.0 (Jahr 2017) gibt es die Razor Pages, die ein Page Model statt eines Controllers besitzen, aber die gleichen Interaktionen mit dem Webbrowser ermöglichen. Lediglich die Architektur auf dem Webserver ist anders, insbesondere die Zusammenarbeit zwischen Page Model und View.
  3. Ebenfalls seit ASP.NET Core 1.0 gibt es das WebAPI-Modell, bei dem der Webserver lediglich Daten per REST-Dienst im JSON-Format an den Webbrowser liefert und das HTML-Rendering sowie die Benutzerinteraktionsereignisbehandlung komplett im Client per JavaScript/TypeScript stattfindet.
  4. An vierter Stelle sieht man nun den ASP.NET Core Blazor Server mit dem kontinuierlichen Zyklus der Übertragung von Interaktionen und DOM-Änderungen via ASP.NET SignalR, sodass der Benutzer das Erlebnis einer Single-Page-Web-Application erhält, wenngleich die Ausführung weiterhin auf dem Server stattfindet. ASP.NET Core Blazor Server ist erstmals in ASP.NET Core 3.0 am 23.9.2019 erschienen.
  5. Das fünfte Architekturmodell ist ASP.NET Core Blazor WebAssembly. Die Serverseite bietet hier wie in Modell 3 nur noch WebAPIs an. C# läuft hier auf Basis der Mono-Runtime in WebAssembly innerhalb des Webbrowsers und kann dort .NET-Code ausführen. Blazor WebAssembly erstellt also eine echte SPA. Es befindet sich bisher noch in der Preview-Phase und soll im Mai 2020 erscheinen.

ASP.NET Core bietet mittlerweile fünf Architekturalternativen (Abb. 1)