|
|
| Zeile 1: |
Zeile 1: |
| | | ==Schwachstellen== |
| -----
| | ===Sprachmodell=== |
| | | * [https://airiskdatabase.com AI Risk Database] – Eine Datenbank mit Risiken und Schwachstellen im Bereich Künstliche Intelligenz. |
| = '''Kurs: Professionelle Webentwicklung mit ASP.NET Core MVC''' = | | * [https://github.com/advisories GitHub CVE & Security Advisories] – Offizielle Sicherheitswarnungen und CVE-Meldungen von GitHub für Open-Source-Projekte. |
| | | * [https://cve.mitre.org/ MITRE CVE Database] – Zentrale Datenbank für öffentlich bekannte Schwachstellen (Common Vulnerabilities and Exposures, CVE). |
| 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.
| | * [https://nvd.nist.gov/ National Vulnerability Database (NVD)] – Die US-amerikanische nationale Datenbank für Schwachstellen, gepflegt vom NIST. |
| | | * [https://www.cvedetails.com/ CVE Details] – Eine benutzerfreundliche Übersicht und Analyse von CVE-Einträgen. |
| -----
| | * [https://www.exploit-db.com/ Exploit Database] – Sammlung von Exploits und Proof-of-Concept-Code für bekannte Schwachstellen. |
| | | * [https://www.securityfocus.com/vulnerabilities SecurityFocus Vulnerability Database] – Archiv von Schwachstellen und Sicherheitsmeldungen. |
| == '''Lektion 1: Das Fundament – Das MVC-Architekturmuster''' == | | * [https://www.openwall.com/lists/oss-security/ Open Source Security (oss-security)] – Mailingliste und Archiv zu Schwachstellen in Open-Source-Software. |
| | | * [https://vuldb.com VulDB] – Community-basierte Schwachstellendatenbank mit aktuellen Informationen und Analysen. |
| 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.
| | * [https://www.zerodayinitiative.com/advisories/published/ Zero Day Initiative Advisories] – Veröffentlichte Schwachstellen und Exploits aus dem Zero Day Initiative Programm. |
| | |
| '''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:
| |
| | |
| # '''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.
| |
| | |
| # '''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.
| |
| | |
| # '''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 <code>.cshtml</code>-Dateien einbetten, um dynamische Inhalte zu erzeugen.
| |
| | |
| * Das <code>@</code>-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 (<code>@Model.Username</code>):''' Geben den Wert einer Variable oder Eigenschaft aus.
| |
| * '''Codeblöcke (<code>@{ ... }</code>):''' Führen eine oder mehrere Zeilen C#-Code aus.
| |
| * '''Kontrollstrukturen:''' Sie können bekannte C#-Strukturen wie <code>if-else</code>, <code>switch</code>, <code>foreach</code> und <code>for</code> 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''' ===
| |
| | |
| <code>ViewData</code> ist ein Wörterbuch-Objekt (<code>Dictionary<string, object></code>), in dem Sie Daten unter einem bestimmten Schlüssel ablegen können.
| |
| | |
| * '''Im Controller:''' <code>ViewData["Titel"] = "Produktliste";</code> | |
| * '''In der View:''' <code><h1>@ViewData["Titel"]</h1></code>
| |
| | |
| Da die Werte als <code>object</code> gespeichert werden, müssen Sie sie bei komplexeren Datentypen oft umwandeln (casten), was fehleranfällig sein kann.
| |
| <code>@(ViewData["Produkt"] as Produkt).Name</code>
| |
| | |
| === '''2. ViewBag''' ===
| |
| | |
| <code>ViewBag</code> ist ein dynamisches Objekt, das im Hintergrund <code>ViewData</code> verwendet, aber eine einfachere Syntax bietet.
| |
| | |
| * '''Im Controller:''' <code>ViewBag.Titel = "Produktliste";</code>
| |
| * '''In der View:''' <code><h1>@ViewBag.Titel</h1></code>
| |
| | |
| '''Vorteile von <code>ViewBag</code>:'''
| |
| * Einfachere, sauberere Syntax (<code>ViewBag.Eigenschaft</code>).
| |
| * Kein explizites Umwandeln (Casting) notwendig. | |
| | |
| '''Nachteil beider Ansätze:''' Es gibt keine Überprüfung zur Kompilierzeit. Ein Tippfehler im Schlüssel (<code>ViewData["Titl"]</code>) oder im Eigenschaftsnamen (<code>ViewBag.Titl</code>) 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:'''
| |
| | |
| # '''Im Controller:''' Sie erstellen eine Instanz Ihres Modells und übergeben diese direkt an die <code>View()</code>-Methode.
| |
| <syntaxhighlight lang="csharp">
| |
| public IActionResult Details(int id)
| |
| {
| |
| Produkt meinProdukt = _db.Produkte.Find(id);
| |
| return View(meinProdukt); // Übergabe des gesamten Objekts
| |
| }
| |
| </syntaxhighlight>
| |
| | |
| # '''In der View:''' Sie deklarieren mit der <code>@model</code>-Direktive, welchen Datentyp die View erwartet.
| |
| <syntaxhighlight lang="csharp">
| |
| @model Projekt.Modelle.Produkt
| |
| | |
| <h1>@Model.Name</h1>
| |
| <p>Preis: @Model.Preis.ToString("c")</p>
| |
| <p>Beschreibung: @Model.Beschreibung</p>
| |
| </syntaxhighlight>
| |
| | |
| '''Die unschlagbaren Vorteile:'''
| |
| * '''IntelliSense:''' Der Editor kennt Ihr Modell und schlägt Ihnen die verfügbaren Eigenschaften vor.
| |
| * '''Kompilierzeit-Sicherheit:''' Tippfehler bei Eigenschaftsnamen (<code>@Model.Naem</code>) 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 <code>Views</code>-Ordner ist der perfekte Ort, um Namespaces zu importieren (<code>@using Projekt.Modelle</code>) oder Tag Helper zu registrieren, die in vielen Views benötigt werden. Der Inhalt von <code>ViewImports.cshtml</code> 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 <code>/Views/Shared</code> abgelegt werden. Wenn ein Controller eine View anfordert, sucht das Framework zuerst im spezifischen Ordner des Controllers (<code>/Views/ControllerName</code>) und danach im <code>/Views/Shared</code>-Ordner.
| |
| | |
| === '''Die View-Auflösung''' ===
| |
| | |
| Zusammenfassend sucht ASP.NET Core eine View <code>MeineView</code> für den <code>HomeController</code> in dieser Reihenfolge:
| |
| # <code>/Views/Home/MeineView.cshtml</code>
| |
| # <code>/Views/Shared/MeineView.cshtml</code>
| |