Kurs:Razor Views

Absolut! Hier ist die Umwandlung des bereitgestellten Markdown-Inhalts in MediaWiki-Syntax:

---

Kurs: Professionelle Webentwicklung mit ASP.NET Core MVC

Willkommen zu diesem Kurs über das Model-View-Controller (MVC) Architekturmuster in ASP.NET Core! Hier lernen Sie, wie Sie saubere, wartbare und skalierbare Webanwendungen entwickeln, indem Sie die Logik Ihrer Anwendung klar strukturieren.

---

Lektion 1: Das Fundament – Das MVC-Architekturmuster

Das Herzstück moderner Webanwendungen ist eine saubere Architektur. Das Model-View-Controller (MVC) Muster ist ein bewährter Ansatz, der den Code in drei logische Hauptkomponenten unterteilt.

Ziele und Vorteile:

• Klare Trennung der Verantwortlichkeiten (Separation of Concerns): Jede Komponente hat genau eine Aufgabe. Das macht den Code verständlicher und Fehler leichter auffindbar.
• Parallele Entwicklung: Teams können gleichzeitig am Datenmodell, der Benutzeroberfläche und der Anwendungslogik arbeiten.
• Einfacheres Testen: Jede Komponente kann isoliert getestet werden (Unit-Testing), was die Qualität Ihrer Software enorm steigert.
• Wartbarkeit: Änderungen in einer Komponente (z. B. im Design der View) haben minimale bis keine Auswirkungen auf die anderen Komponenten.

Das wichtigste Prinzip ist die Unabhängigkeit des Models. Es kennt weder die View noch den Controller und kann daher völlig eigenständig entwickelt und getestet werden.

---

Lektion 2: Die drei Hauptakteure und ihre Rollen

Um das MVC-Muster zu verstehen, müssen wir die Verantwortlichkeiten der einzelnen Komponenten kennen. Stellen Sie sich den Ablauf einer Anfrage vor:

1. Der Controller: Der Dirigent
   • Empfängt die HTTP-Anfrage des Benutzers (z. B. das Aufrufen einer URL).
   • Er ist der Koordinator: Er ruft das Geschäftsmodell auf, um Daten abzufragen oder zu bearbeiten.
   • Anschließend wählt er die passende View aus, um die Daten darzustellen.

1. Das Geschäftsmodell (Model): Das Gehirn
   • Enthält die gesamte Geschäftslogik und die Daten Ihrer Anwendung.
   • Führt Operationen aus, wie z. B. das Lesen und Schreiben von Daten in einer Datenbank.
   • Es ist die "Quelle der Wahrheit" und gibt die verarbeiteten Daten an den Controller zurück. Es hat keinerlei Kenntnis von der Benutzeroberfläche.

1. Die View: Das Gesicht
   • Ist für die reine Darstellung der Daten verantwortlich (HTML-Code).
   • Sie empfängt die vom Controller vorbereiteten Daten und stellt sie dar.
   • Die View selbst enthält keine Geschäftslogik. Sie sollte nur Code enthalten, der für die Präsentation notwendig ist.

Der Datenfluss im Überblick: Anfrage → Controller → Ruft Model auf → Model liefert Daten zurück → Controller übergibt Daten an View → View wird gerendert und als Antwort an den Benutzer gesendet.

---

Lektion 3: Dynamische Ansichten mit der Razor View Engine

Eine View ist mehr als nur statisches HTML. Mit der Razor View Engine können wir C#-Code direkt in unsere .cshtml-Dateien einbetten, um dynamische Inhalte zu erzeugen.

• Das @-Zeichen leitet Razor-Syntax ein.
• Razor ermöglicht es uns, Daten aus unserem Modell direkt im HTML auszugeben und Logik für die Darstellung zu implementieren.

Wichtige Razor-Konstrukte:

• Ausdrücke (@Model.Username): Geben den Wert einer Variable oder Eigenschaft aus.
• Codeblöcke (@{ ... }): Führen eine oder mehrere Zeilen C#-Code aus.
• Kontrollstrukturen: Sie können bekannte C#-Strukturen wie if-else, switch, foreach und for verwenden, um die Darstellung zu steuern.
• Lokale Funktionen: Sie können kleine Hilfsfunktionen direkt in Ihrer View definieren.

Wichtig: Die Logik in einer View sollte sich ausschließlich auf die Präsentation beschränken! Komplexe Berechnungen gehören in das Model oder den Controller.

---

Lektion 4: Daten vom Controller an die View übergeben

Doch wie gelangen die Daten vom Controller in die View? Dafür gibt es mehrere Mechanismen. Wir beginnen mit zwei einfachen, aber "schwach typisierten" Ansätzen.

1. ViewData

ViewData ist ein Wörterbuch-Objekt (Dictionary<string, object>), in dem Sie Daten unter einem bestimmten Schlüssel ablegen können.

• Im Controller: ViewData["Titel"] = "Produktliste";
• In der View: <h1>@ViewData["Titel"]</h1>

Da die Werte als object gespeichert werden, müssen Sie sie bei komplexeren Datentypen oft umwandeln (casten), was fehleranfällig sein kann. @(ViewData["Produkt"] as Produkt).Name

2. ViewBag

ViewBag ist ein dynamisches Objekt, das im Hintergrund ViewData verwendet, aber eine einfachere Syntax bietet.

• Im Controller: ViewBag.Titel = "Produktliste";
• In der View: <h1>@ViewBag.Titel</h1>

Vorteile von ViewBag:

• Einfachere, sauberere Syntax (ViewBag.Eigenschaft).
• Kein explizites Umwandeln (Casting) notwendig.

Nachteil beider Ansätze: Es gibt keine Überprüfung zur Kompilierzeit. Ein Tippfehler im Schlüssel (ViewData["Titl"]) oder im Eigenschaftsnamen (ViewBag.Titl) wird erst zur Laufzeit als Fehler bemerkt.

---

Lektion 5: Der Königsweg – Stark typisierte Views

Für robuste und wartbare Anwendungen ist die Verwendung von stark typisierten Views der empfohlene Standard. Eine stark typisierte View ist fest an eine bestimmte Modellklasse gebunden.

Und so funktioniert's:

1. Im Controller: Sie erstellen eine Instanz Ihres Modells und übergeben diese direkt an die View()-Methode.

public IActionResult Details(int id)
{
    Produkt meinProdukt = _db.Produkte.Find(id);
    return View(meinProdukt); // Übergabe des gesamten Objekts
}

1. In der View: Sie deklarieren mit der @model-Direktive, welchen Datentyp die View erwartet.

@model Projekt.Modelle.Produkt

<h1>@Model.Name</h1>
<p>Preis: @Model.Preis.ToString("c")</p>
<p>Beschreibung: @Model.Beschreibung</p>

Die unschlagbaren Vorteile:

• IntelliSense: Der Editor kennt Ihr Modell und schlägt Ihnen die verfügbaren Eigenschaften vor.
• Kompilierzeit-Sicherheit: Tippfehler bei Eigenschaftsnamen (@Model.Naem) führen zu einem Kompilierfehler und werden sofort entdeckt.
• Klarheit: Es ist sofort ersichtlich, welche Daten diese View für ihre Darstellung benötigt.

---

Lektion 6: Code organisieren und wiederverwenden

Für größere Projekte sind Struktur und Wiederverwendbarkeit entscheidend.

ViewImports.cshtml

Diese spezielle Datei im Views-Ordner ist der perfekte Ort, um Namespaces zu importieren (@using Projekt.Modelle) oder Tag Helper zu registrieren, die in vielen Views benötigt werden. Der Inhalt von ViewImports.cshtml wird automatisch auf alle Views im selben Ordner und in Unterordnern angewendet.

Geteilte Views (Shared Views)

Views, die von mehreren Controllern verwendet werden (z. B. Layout-Dateien, Navigationsleisten, Fehlerseiten), sollten im Ordner /Views/Shared abgelegt werden. Wenn ein Controller eine View anfordert, sucht das Framework zuerst im spezifischen Ordner des Controllers (/Views/ControllerName) und danach im /Views/Shared-Ordner.

Die View-Auflösung

Zusammenfassend sucht ASP.NET Core eine View MeineView für den HomeController in dieser Reihenfolge:

1. /Views/Home/MeineView.cshtml
2. /Views/Shared/MeineView.cshtml