ASP.NET Core Razor Pages

Eintrag zuletzt aktualisiert am: 24.05.2022

ASP.NET Core Razor Pages sind erstmals erschienen in ASP.NET Core 2.0 im Jahr 2017.

Die Razor Pages sind der Nachfolger von MVC in der Welt von ASP.NET Core. Auch wenn MVC weiterhin parallel unterstützt wird, hat Microsoft die Razor Pages zum neuen bevorzugten Anwendungsmodell erklärt.

Sicherlich wird es wieder einige Entwickler geben, die jetzt unzufrieden sind zu hören, dass Microsoft ein neues favorisiertes Modell für das Server Side Rendering hat. Dieses Kapitel wird aufzeigen, dass die Razor Pages einige deutliche Vorteile gegenüber MVC hinsichtlich der Übersichtlichkeit und der Datenbindung haben. Es sind aber auch noch Schwächen da: [TempData] erlaubt keine komplexen Datentypen und funktioniert nicht zusammen mit [BindingProperty]. Wenn Microsoft das noch ändern würde, könnten wir uns beim Codieren von Razor Pages noch einige Programmzeilen sparen.

Denen, die nicht von Razor Pages überzeugt sein werden, sei jetzt schon gesagt, dass das MVC-Framework weiterhin in ASP.NET Core existiert, zumal es ja auch die Grundlage für die Web APIs in ASP.NET Core ist: Sowohl MVC als auch Web APIs verwenden die Basisklasse Controller. Daher ist keine Migration auf Razor Pages erforderlich. Ob und wann Microsoft MVC wegfallen lässt, können nur die Wahrsager sagen. Grundsätzlich nimmt die Anzahl der Webanwendungen mit serverseitigem Rendering immer mehr ab und Kunden migrieren eher zu clientseitigem Rendering mit Angular, React, Aurelia, VueJS & Co.

Razor Pages versus MVC

---

Razor Pages sind .cshtml-Dateien mit Razor Syntax, die Startdeklaration ist @page. Der Standardordner für die Razor Pages in einem ASP.NET Core-Webprojekt ist der Ordner /Pages. Anders als MVC gibt es hier aber keinen Controller. Es kann (es muss aber nicht) eine Page Model-Klasse zu einer Razor Page geben. In Visual Studio erhält man auf dem /Pages-Ordner die Funktion "Add Razor Page" mit der Auswahl zwischen einer einfachen Razor Page und einer, die Entity Framework Core verwendet.

Eine Razor Page ohne Page Model kann beliebig viel Programmcode enthalten. Dies ist aber nur etwas für Liebhaber der Verstrickung zwischen Programmcode und HTML, wie man es aus PHP kennt. Die meisten Entwickler werden eine getrennte Code-Datei bevorzugen. Auf die dort realisierte Klasse verweist der Entwickler mit der @model-Direktive. Danach folgen weitere Deklarationen wie bei MVC, z.B.
 Verweis auf Layout-Seite (Masterpage)
 Setzen von Werten für die Layout-Seite, z.B. Titel
 Einbinden der Standard Tag Helper von ASP.NET Core
 Einbinden eigener Tag Helper

Das folgende Codefragment zeigt ein typisches Beispiel für den Beginn eines Razor Page-Views:

@page
@model Miraclelist_WebAPI.Pages.ClientIDModel
@{
Layout = "~/Views/Shared/_Layout.cshtml";
ViewData["Title"] = "ClientID beantragen";
}
@addTagHelper *,Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *,ITVisionsTagHelper

Razor Pages beachten leider nicht globale Deklarationen in /Views/Shared/ViewStart.cshtml und /Views/Shared/ViewImports.cshtml. Sie können aber die gleiche Layout-Datei wie MVC-Views im gleichen Webprojekt verwenden.

Wichtig ist, dass Routen nicht doppelt belegt werden. Wenn Routen ambivalent sind, gewinnt die Razor Page.

Beispiel: Es gibt einen Controller ClientID.cs mit einer Action-Methode Index() und einen View /Views/ClientID/Index. Dieser View wird gezeigt, wenn man http://servername/clientid aufrufen. Wenn man nun aber auch eine Razor Page /Pages/ClientID.cshtml anlegt, dass reagiert diese ebenso auf die Route http://servername/clientid. Der obige View ist dann nicht mehr auf dieser Route erreichbar.