Model-View-Controller (MVC) — Eingabe, Aktualisierung, Rendern

Model-View-Controller (MVC) — Eingabe, Aktualisierung, Rendern

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Folgen Sie der Schleife in der Reihenfolge, in der die Pfeile sie zeichnen: Nutzer zum Controller zum Model zur View und zurück zum Nutzer.
• Die drei Spalten sind die drei Akte: Die Eingabe kommt an, der Zustand wird aktualisiert, die Ausgabe wird gerendert.
• Die Bahnen sind die Trennung der Zuständigkeiten — jede Bahn besitzt eine Art von Arbeit, und keine Bahn erledigt die einer anderen.

Eingabe

„Nutzer bedient die Oberfläche“ startet die Schleife, und „Controller empfängt die Eingabe“ ist der Verkehrspolizist: Er liest die Aktion, entscheidet, was sie bedeutet, und weist das Model an. Der Kommentar am Controller macht die Regel ausdrücklich — er hält selbst keinen Zustand, und deshalb kann er viele Anfragen bearbeiten, ohne sich etwas zu merken.

Aktualisierung

„Controller aktualisiert das Model“ überschreitet die Grenze in die Bahn des Models, und „Model hält Zustand und Geschäftsregeln“ ist dessen Definition: Es ist die einzige Quelle der Wahrheit für die Daten und die Regeln, die für sie gelten. „Model meldet die Änderung an die Observer“ ist die Hälfte der Benachrichtigung — das Model sagt der View nicht, was sie zeichnen soll, es kündigt nur an, dass sich etwas geändert hat, und beliebig viele Views können zuhören.

Rendern

„View rendert neu aus dem Model“ ist die einzige Aufgabe der View: das Model lesen und anzeigen. Ihr Kommentar hält die Disziplin fest, an der MVC nicht zerfällt — die View ändert nie Daten, sie fragt nur und zeigt an. „Nutzer sieht die aktualisierte Oberfläche“ schließt den Kreis zurück in der Zeile des Nutzers, wo jede Interaktion sowohl beginnt als auch endet.

Wichtige Zusammenhänge und Erkenntnisse

• Der Controller nimmt die Eingabe entgegen, das Model besitzt den Zustand, die View rendert — drei Zuständigkeiten, drei Bahnen.
• Weder die View noch der Controller schreibt Daten; alle Änderungen laufen durch das Model.
• Das Model meldet an Observer, statt der View Befehle zu geben, und deshalb kann ein Model viele Views versorgen.
• Die Trennung macht jeden Teil für sich prüfbar — der ursprüngliche Gewinn des Musters.
• MVC ist der Vorfahr vieler moderner Muster (MVVM, MVP, Stores im Redux-Stil), die alle dieselbe Trennung bewahren.

Wann Sie diese Darstellung nutzen

• Einer Entwicklerin oder einem Entwickler das Muster vorstellen, bevor sie die Dokumentation eines Frameworks lesen — das Dreieck ist die Karte, die jedes Framework umsetzt.
• Erklären, warum sich eine Codebasis schwer ändern lässt: Zustand, der in der View verwaltet wird, verstößt gegen MVC, und auf der Zeichenfläche ist das sichtbar.
• MVC mit den geschichteten Architekturen der Darstellung zur Clean Architecture vergleichen.

So funktioniert es

1. Übertragen Sie Ihr Framework auf das Dreieck

   Benennen Sie die drei Kästen mit den Teilen Ihres tatsächlichen Frameworks um — eine Routendatei als Controller, Ihre ORM-Modelle als Model, Ihre Templates als View —, damit das Muster konkret wird.

2. Ergänzen Sie den Schritt des Routings

   Fügen Sie zwischen Nutzer und Controller einen Schritt für das Routing ein, falls Ihr Framework einen hat, verbunden mit dem Controller, an den er weiterreicht.

3. Zeigen Sie mehrere Views

   Fügen Sie einen zweiten Kasten für eine View hinzu, die auf dasselbe Model hört — eine Listen- und eine Detailansicht —, um die Observer-Beziehung zu zeigen, auf der das Muster beruht.

4. Ergänzen Sie die Schicht der Persistenz

   Erweitern Sie das Model um einen Schritt für die Datenbank und vermerken Sie, dass das Model sie besitzt und Controller wie View sie nie direkt anfassen.

Häufig gestellte Fragen

Was ist MVC?

MVC — Model-View-Controller — ist ein Softwaremuster, das eine Anwendung in drei Teile trennt: Der Controller nimmt die Eingabe entgegen, das Model besitzt die Daten und die Geschäftsregeln, und die View rendert das Model. Der Gewinn dieser Trennung ist, dass sich jeder Teil unabhängig entwickeln und prüfen lässt und dass dasselbe Model von vielen Views gezeigt werden kann. Es ist das Muster, auf dem die meisten Web-Frameworks aufbauen.

Warum steht das Model im Zentrum von MVC?

Weil das Model die einzige Quelle der Wahrheit ist. Könnten Controller und View beide Daten schreiben, würden sie auseinanderlaufen und über den Zustand streiten. Alle Änderungen im Model zu halten bedeutet, dass es genau einen Ort für die Datenregeln gibt und die View immer die Projektion eines stimmigen Models ist. Genau deshalb stellt die Darstellung beide Kästen des Models in eine eigene Bahn.

Was passiert, wenn ich Logik in die View lege?

Sie erhalten ein Anti-Pattern, das gelegentlich „fat view“ genannt wird: Anzeigecode vermischt mit Geschäftsregeln, der sich ohne Rendern nicht prüfen lässt und vom Model abdriftet. Dieselbe Kritik trifft einen Controller, der Geschäftslogik hält, statt sie weiterzureichen. Die Disziplin von MVC lautet, dass jede Bahn in ihrer Bahn bleibt — die drei getrennten Zeilen der Darstellung sind diese Regel, sichtbar gemacht.

Wie verhält sich MVC zu modernen Frameworks?

Die meisten modernen Frameworks bewahren das Dreieck unter neuen Namen: MVVM ergänzt eine Schicht View-Model, MVP gibt der View einen Presenter, und Bibliotheken zur Zustandsverwaltung wie Redux sind im Kern das Model mit einer strengeren Regel für Benachrichtigungen. Die zentrale Schleife der Zeichenfläche — die Eingabe ändert den Zustand, der Zustand treibt die Ausgabe — ist die Konstante, die jede von ihnen behält.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese MVC-Zeichenfläche als eigenes Diagramm, benennen Sie die Kästen auf Ihr Framework um und verfolgen Sie Ihren eigenen Weg der Anfrage.

Diese Darstellung in QueryChart (FlowJam) bearbeiten