Sie sind hier: Startseite | Wissen

Was ist ASP.NET Core Razor Pages?

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


Die Abbildung zeigt den Vergleich zwischen MVC und Razor Pages im Schaubild. 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.


Abbildung: Seitenaufbau und Seitenwechsel in MVC und Razor Pages
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.

Beratung & Support:

Schulungen zu diesem Thema:

 Anfrage für eine individuelle Schulung zum Thema ASP.NET Core Razor Pages;  Gesamter Schulungsthemenkatalog

Bücher zu diesem Thema:

 Alle unsere aktuellen Fachbücher