ASP .NET vs Razor (Wie es für Entwickler funktioniert)

1.1 ASP.NET

Seit seiner Einführung ist ASP.NET das Fundament von Microsofts Webentwicklungs-Framework. Auf dem robusten .NET-Framework aufgebaut, gibt es Entwicklern die vollständige Kontrolle über ihre Webanwendungen durch sein leistungsfähiges .NET MVC (Model View Controller) Muster. Das ASP.NET Core MVC-Framework eignet sich hervorragend zum Erstellen von Webanwendungen, die komplexe Architektur-Muster und umfangreiche Anpassungen erfordern.

1.2 Rasierer

Razor stellt einen modernen Ansatz f\u00fcr die Webentwicklung dar, der als Teil des ASP.NET Core-\u00d6kosystems eingef\u00fchrt wurde. Es ist eine leistungsstarke View-Engine, die die serverseitige Code-Integration mit HTML vereinfacht. Razor Pages bietet ein seitenzentriertes Szenario, das die Webentwicklung intuitiver und unkomplizierter macht.

3.1 Architektonischer Ansatz

Das Architektur-Muster stellt den grundlegendsten Unterschied zwischen diesen Ansätzen dar. ASP.NET Core MVC folgt dem traditionellen Model View Controller Muster mit drei miteinander verbundenen Komponenten. Jede Anfrage fließt durch ein Routersystem zu den entsprechenden MVC-Controllern, die dann mit dem Modell interagieren und die richtige Ansicht auswählen.

Im Gegensatz dazu verfolgt Razor Pages einen einfacheren, auf Seiten fokussierten Ansatz. Jede Razor-Seite hat ihre eigene PageModel-Klasse, die das Datenmodell und die Benutzereingaben verwaltet. Diese Struktur eliminiert die Notwendigkeit für riesige Controller-Klassen und vereinfacht das Einreichen von Formularen und das Datenbinding.

3.2 Muster der Anfragebehandlung

Das Muster der Anfragenbearbeitung unterscheidet sich erheblich zwischen den beiden. In MVC werden Anfragen durch Controller mit Aktionen geroutet, die Ansichten zurückgeben. Ein typischer MVC-Controller-Code sieht so aus:

public class HomeController : Controller
{
    public string Message { get; private set; }

    public IActionResult Index()
    {
        // Return the view associated with this action
        return View();
    }
}

public class HomeController : Controller
{
    public string Message { get; private set; }

    public IActionResult Index()
    {
        // Return the view associated with this action
        return View();
    }
}

In der Zwischenzeit verarbeitet Razor Pages Anfragen direkt im PageModel mit Methoden wie OnGet und OnPost:

public class IndexModel : PageModel
{
    public string Title { get; private set; }

    public void OnGet()
    {
        // Handle GET request and initialize data for the view
    }
}

public class IndexModel : PageModel
{
    public string Title { get; private set; }

    public void OnGet()
    {
        // Handle GET request and initialize data for the view
    }
}

3.3 Aufbau und Struktur der Seite

Razor Pages organisieren Code in einer Seiten-Ordnerstruktur, wobei jede Seite in sich geschlossen mit ihrer Ansicht und ihrem Modell ist. MVC hingegen trennt diese Belangen in unterschiedliche Ordner für Modelle, Ansichten und Controller. Dieser grundlegende Unterschied beeinflusst, wie Entwickler ihren Code organisieren und pflegen.

3.4 Datenfluss und Bindung

MVC implementiert den Datenfluss durch Controller-Aktionen, Modellbindung und Ansichtsdarstellung, mit expliziter Kontrolle über jeden Schritt. Razor Pages vereinfacht dies durch bidirektionale Datenbindung und automatische Modellbindung durch das PageModel. Dies macht das Einreichen von Formularen und das Handling von Validierungsfehlern in Razor Pages unkomplizierter.

3.5 Wiederverwendbarkeit von Komponenten

Während beide Frameworks View-Komponenten und Tag-Helper unterstützen, handhaben sie die Wiederverwendbarkeit unterschiedlich. MVC ermöglicht eine detailliertere Kontrolle durch Partial Views und Child-Actions, während Razor Pages seitenbasierte Komponenten und geteilte Layouts betont. Das MVC-Muster bietet mehr Optionen zur Erstellung wiederverwendbarer Komponenten über verschiedene Ansichten hinweg.

3.6 Entwicklungskomplexität

Die Lernkurve und Entwicklungs-Komplexität variieren erheblich zwischen den beiden Ansätzen. MVC's Trennung der Belange durch drei miteinander verbundene Komponenten erfordert mehr anfängliche Einrichtung, bietet jedoch größere Flexibilität. Razor Pages' vereinfachte Struktur macht es einfacher, zu beginnen, kann jedoch zusätzliche Arbeit für komplexe Szenarien erfordern.

4.1 Vorteile von ASP.NET Core MVC

• Das MVC-Framework glänzt in Szenarien, die isolierte Belange und komplexe Architektur-Muster erfordern
• Bietet Entwicklern vollständige Kontrolle über die Anwendungsstruktur
• Unterstützt umfangreiche Anpassungen
• Reifes Ökosystem bietet robuste Lösungen zur Handhabung von REST-APIs
• Starke Unterstützung für Dependency Injection und komplexe Routing-Szenarien
• MVVM-Lösungsmuster ist gut unterstützt
• Effiziente Handhabung dynamischer Serveransichten
• Tag-Helper und View-Komponenten bieten leistungsstarke Werkzeuge zur Erstellung wiederverwendbarer UI-Komponenten

4.2 Nachteile von ASP.NET Core MVC

• Steile Lernkurve für Neueinsteiger
• Herausforderungen beim Verständnis der miteinander verbundenen Komponenten des MVC-Musters
• Management riesiger Controller-Klassen kann in größeren Anwendungen schwierig werden
• Trennung der Belange, obwohl vorteilhaft, kann zu erhöhter Komplexität führen

4.3 Vorteile von Razor Pages

• Glänzt in seitenzentrierten Szenarien
• Bietet ein einfacheres Entwicklungsmodell, das für kleinere Webanwendungen geeignet ist
• Starke Unterstützung für bidirektionale Datenbindung und Formularsteuerung
• Eingebaute Unterstützung für Validierungsfehler und AJAX-Anrufe
• Klare Organisation durch die Seiten-Ordnerstruktur
• Intuitive Razor-Syntax zum Mischen von HTML und serverseitigem Code
• Unkomplizierter Ansatz zur Handhabung von Formulareinreichungen und Benutzereingaben
• Reduzierte Entwicklungszeit

4.4 Nachteile von Razor Pages

• Eignet sich möglicherweise nicht optimal für komplexe Anwendungen, die umfangreiche Architektur-Muster erfordern
• Seitenmodellansatz kann im Vergleich zu MVC Controllern die Flexibilität einschränken
• Vereinfachte Architektur könnte sich nicht gut für Unternehmensanwendungen skalieren lassen
• Weniger geeignet für Anwendungen, die komplexes Routing und Controller-Logik erfordern