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 [Binding
Property]. 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 HelperDas 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.
Sind die Inhalte hilfreich?