Razor Pages ist eine neue Funktion, die in Core.Net 2.0 eingeführt wurde. Razor Page ist eine Seite, die aus einem Standardlayout (Ansicht) und einer Backend-Klasse besteht. In gewissem Sinne ähnelt es Web Forms nur ohne staatliche Unterstützung. Der Vorteil einer solchen Lösung liegt auf der Hand - wir beseitigen eine unnötige Ebene - das Seitenmodell (ein Datenmodell in Form von beispielsweise Entität ist für sich). Das Seiten-Backend ist sowohl ein Controller als auch ein Modell - OOP classic -, das Daten und Methoden für die Arbeit mit ihnen in einem Objekt zusammenfasst. Am Ende ist das Seitenmodell nur eine Klasse. Es gibt keinen Grund, warum der Controller nicht diese Klasse sein kann.
Mit anderen Worten, Razor Pages ist eine vernünftigere Weblösung als MVC. Jetzt beschäftigen wir uns mit dem traditionellen und logischen Konzept der „Seite“ und nicht mit Controllern und Modellen, die über das gesamte Projekt verteilt sind. Da sich .NET jedoch in Richtung Core.Net entwickeln wird, ist es unwahrscheinlich, dass Razor Page im Standardframework angezeigt wird, obwohl die meisten Projekte in den kommenden Jahren auf Standard .NET verbleiben. Trotzdem ist es möglich, die Funktionalität von Razor Pages in einem Standard-Framework darzustellen.
Die Lösung sieht eigentlich ziemlich trivial aus - Sie müssen dem Controller das folgende Design hinzufügen:
protected override void OnActionExecuting(ActionExecutingContext Context) { UpdateModel(this); }
Die OnActionExecuting-Methode ist ein Ereignis des Lebenszyklus, das aufgerufen wird, bevor die Controller-Methode ausgeführt wird (dh der Anforderungshandler - Aktion).
UpdateModel bindet die Anforderungsparameter direkt an die Eigenschaften des Modells - in diesem Fall an die Eigenschaften der Controller-Klasse.
Ein zusätzlicher Komfort - jetzt müssen Parameter vom Typ Modell oder andere nicht mehr explizit akzeptiert werden. Obwohl dies nichts verhindert, sind Bindungsparameter als Eigenschaften des Controllers erforderlich, wenn der Parameter eine einfache ID ist, die lediglich als lokale Variable verwendet wird, beispielsweise wenn Sie die Persistenz der Seite sicherstellen müssen, was später erläutert wird.
Ein einfaches Beispiel:
Wir haben das übliche Anmeldeformular mit zwei Feldern.
Es macht keinen Sinn, sich zu markieren, ich werde nur den Controller-Code geben
public class AccountController : Controller { public string username{ get; set; } public string userpass{ get; set; } [HttpPost] public ActionResult OnLogin( ) {
Wie Sie sehen, sind die Eingabedaten zum Zeitpunkt der Auslösung des Ereignisses bereits gebunden und einsatzbereit.
Natürlich müssen wir bedenken, dass wir jetzt auch den Controller als ActionResult zurückgeben und in der Vorlage den Klassennamen des Controllers registrieren müssen - wie z. B. @Model AccountController.
Infolge dieser Lösung wird auch die Aufgabe, den Status der Seite zwischen Anforderungen beizubehalten, vereinfacht. Angenommen, Sie haben eine Seite mit einer bestimmten Tabelle, einem Filter, der nach Spalten und Paginierung sortiert ist.
Wenn Sie auf den Filter klicken, kehrt das Modell zur Ansicht zurück und alles ist in Ordnung. Wenn Sie jedoch auf Sortieren klicken, wird der Filter natürlich zurückgesetzt. Der Paginator setzt sowohl die Sortierung als auch den Filter zurück. In WebForms wurde der Status der Seite automatisch gespeichert. In MVC müssen Sie verschiedene umständliche Entscheidungen treffen. Kleben Sie beispielsweise alle Parameter und steuern Sie sie für jede Anforderung. Das heißt, Sie müssen alle zuvor eingegebenen Parameter vom Filter an den Sortierlink hängen.
Solche Schwierigkeiten sind einer der Gründe für SPA und anderen Javascript-Wahnsinn, Logik und Daten mit den daraus resultierenden Browserbremsen (insbesondere mobilen Geräten) in den Browser zu ziehen, Seiten für jede Mausbewegung zu springen und zu ruckeln und die Komplexität und die Kosten der Arbeit zu erhöhen - denn das Backend ist alle gleich Schreiben Sie in der einen oder anderen Form, packen Sie die über Ajax gesendeten Daten aus, plus Callbac Hell, Komplikationen beim Debuggen usw. und dies alles ohne praktischen Nutzen für Website-Besucher, denen es egal ist, wie Isana Seite.
Die logischste Lösung besteht darin, den Seitenstatus in der Sitzung zu speichern. Da wir alle erforderlichen Parameter in Form von Controller-Eigenschaften zur Hand haben, müssen Sie lediglich die OnActionExecuted-Methode neu definieren, die nach der Verarbeitung der Anforderung aufgerufen wird, und die erforderlichen Eigenschaften in die Sitzung packen (der Sitzungsschlüssel sollte offensichtlich auf den Namen des Controllers verweisen).
protected override void OnActionExecuted (ActionExecutedContext Context) {
Die Parameter werden aus der Sitzung im Controller-Konstruktor oder vor dem Aufruf von UpdateModel (this) wiederhergestellt. Wenn eine Anforderung eintrifft, z. B. Sortierungen, ändern sich die neuen Parameter und der Rest bleibt unberührt, und die Ansicht wird in derselben Form angezeigt, in der sie gesendet wurde.
Eine solche Lösung bietet noch einen weiteren Vorteil: Der Benutzer hat beispielsweise die Tabelle sortiert und beschlossen, ein Element zu bearbeiten, indem er eine andere Seite dafür öffnet. Natürlich möchte er zum Status der Liste zurückkehren, die er verlassen hat, und da sich der Status der Seite in unserer Sitzung befindet, wird die Seite automatisch wiederhergestellt. Wie so oft ist es nicht erforderlich, den gesamten "Knödel" der Parameter auf die Bearbeitungsseite zu übertragen und umgekehrt. Wenn der Status zwischen den Seiten nicht gespeichert werden muss, kann der Status der Seite nicht in einer Sitzung, sondern in TempData gespeichert werden.
Ich hoffe, dass diese „Life Hacks“, obwohl sie trivial aussehen, für Anfänger nützlich sind, bis sie im Internet nach unbequemeren und umständlicheren Lösungen suchen und feststellen, dass es keine anderen gibt.