MVC-Ansatz

Einführung in die MVC-Architektur

Die beliebteste Anwendungsarchitektur, die jeder Programmierer kennt, ist MVC . MVC steht für Model-View-Controller .

Hierbei handelt es sich weniger um die Architektur von Anwendungen als vielmehr um die Architektur von Anwendungskomponenten, aber wir werden später auf diese Nuance zurückkommen. Was ist MVC?

MVC ist ein Schema zur Aufteilung von Anwendungsdaten und Steuerlogik in drei separate Komponenten – Modell, Ansicht und Controller –, sodass jede Komponente unabhängig geändert werden kann.

• Modell (Modell) stellt Daten bereit und reagiert auf Controller-Befehle, indem es seinen Zustand ändert.
• Die Ansicht ist dafür verantwortlich, dem Benutzer als Reaktion auf Modelländerungen Modelldaten anzuzeigen.
• Der Controller (Controller) interpretiert die Aktionen des Benutzers und benachrichtigt das Modell über die Notwendigkeit von Änderungen.

Dieses Modell wurde bereits im 1978 (!) Jahr erfunden. Ja, Probleme mit der richtigen Softwarearchitektur waren vor 50 Jahren relevant. So wird dieses Modell durch das Diagramm im Original beschrieben:

Das Modell stellt Daten und Methoden für die Arbeit mit ihnen bereit: Abfragen an die Datenbank, Überprüfung auf Korrektheit. Das Modell ist unabhängig von der Ansicht (weiß nicht, wie Daten gerendert werden) und dem Controller (verfügt über keine Benutzerinteraktionspunkte) und ermöglicht den Zugriff auf und die Verwaltung von Daten.

Das Modell ist so aufgebaut, dass es auf Anfragen reagiert, indem es seinen Zustand ändert, und die Benachrichtigung von „Beobachtern“ kann eingebaut werden. Das Modell kann aufgrund der Unabhängigkeit von der visuellen Darstellung mehrere unterschiedliche Darstellungen für ein „Modell“ haben .

Die Ansicht ist dafür verantwortlich, die erforderlichen Daten aus dem Modell abzurufen und an den Benutzer zu senden. Die Ansicht verarbeitet keine Benutzereingaben.

Der Controller sorgt für die „Kommunikation“ zwischen dem Benutzer und dem System. Steuert und leitet Daten vom Benutzer zum System und umgekehrt. Verwendet ein Modell und eine Ansicht, um die gewünschte Aktion umzusetzen.

Eine gewisse Schwierigkeit besteht darin, dass sich dieses Modell im Laufe der Jahrzehnte ein wenig weiterentwickelt hat. Das heißt, der Name blieb derselbe, aber der Zweck der Teile begann sich zu ändern.

MVC-Architektur im Web

Die Idee hinter dem MVC-Entwurfsmuster ist sehr einfach: Wir müssen die Verantwortung für unterschiedliche Verhaltensweisen in unseren Anwendungen klar trennen:

Modell— Datenverarbeitung und Anwendungslogik.

Sicht– Bereitstellung von Daten für den Benutzer in jedem unterstützten Format.

Regler- Bearbeitung von Benutzeranfragen und Aufruf der entsprechenden Ressourcen.

Die Anwendung ist in drei Hauptkomponenten unterteilt, die jeweils für unterschiedliche Aufgaben zuständig sind. Schauen wir uns die Komponenten einer Client-Server-Anwendung anhand eines Beispiels genauer an.

Regler

Der Benutzer klickt im Browser auf verschiedene Elemente der Seite, woraufhin der Browser verschiedene HTTP-Anfragen sendet: GET, POST oder andere. Der Controller kann den Browser und den JS-Code einbinden, die innerhalb der Seite funktionieren.

Die Hauptfunktion des Controllers besteht in diesem Fall darin, Methoden für die erforderlichen Objekte aufzurufen und den Zugriff auf Ressourcen zu verwalten, um vom Benutzer angegebene Aufgaben auszuführen. Normalerweise ruft der Controller das entsprechende Modell für die Aufgabe auf und wählt die entsprechende Ansicht aus.

Modell

Ein Modell im weitesten Sinne sind die Daten und Regeln, die zur Arbeit mit den Daten verwendet werden – zusammen bilden sie die Geschäftslogik der Anwendung. Das Entwerfen einer Anwendung beginnt immer mit der Erstellung von Modellen der Objekte, auf denen sie ausgeführt wird.

Nehmen wir an, wir haben einen Online-Shop, der Bücher verkauft. Ist eine Person dann nur ein Anwendungsbenutzer oder auch ein Autor eines Buches? Diese wichtigen Fragen müssen beim Modellentwurf berücksichtigt werden.

Darüber hinaus gibt es Regelwerke: Was kann getan werden, was nicht, welche Datensätze sind akzeptabel und welche nicht. Kann ein Buch ohne Autor existieren? Und der Autor ohne Bücher? Kann das Geburtsdatum des Benutzers im Jahr 300 usw. liegen?

Das Modell gibt dem Controller einen Einblick in die Daten, die der Benutzer angefordert hat (Nachricht, Buchseite, Bilder usw.). Das Datenmodell bleibt dasselbe, unabhängig davon, wie wir es dem Benutzer präsentieren möchten. Daher wählen wir eine beliebige verfügbare Ansicht zur Anzeige der Daten.

Das Modell enthält den wichtigsten Teil unserer Anwendungslogik , die Logik, die das Problem löst, mit dem wir es zu tun haben (Forum, Shop, Bank usw.). Der Controller enthält hauptsächlich Organisationslogik für die Anwendung selbst (genau wie Ihr Projektmanager).

Sicht

View bietet verschiedene Möglichkeiten zur Darstellung der vom Modell empfangenen Daten. Dabei kann es sich um eine mit Daten gefüllte Vorlage handeln. Es kann mehrere verschiedene Ansichten geben und der Controller wählt aus, welche für die aktuelle Situation am besten ist.

Eine Webanwendung besteht normalerweise aus einer Reihe von Controllern, Modellen und Ansichten. Der Controller kann sich nur auf dem Backend befinden, es kann aber auch eine Variante aus mehreren Controllern geben, wenn seine Logik auch über das Frontend verteilt ist. Ein gutes Beispiel für diesen Ansatz ist jede mobile Anwendung.

MVC-Beispiel im Web

Nehmen wir an, Sie müssen einen Online-Shop entwickeln, der Bücher verkauft. Der Benutzer kann folgende Aktionen ausführen: Bücher ansehen, registrieren, kaufen, Artikel zur aktuellen Bestellung hinzufügen, Bücher markieren, die ihm gefallen, und sie kaufen.

Ihre Anwendung sollte über ein Modell verfügen , das für die gesamte Geschäftslogik verantwortlich ist. Sie benötigen außerdem einen Controller , der alle Benutzeraktionen verarbeitet und sie in Methodenaufrufe der Geschäftslogik umwandelt. Allerdings kann eine Controller-Methode viele verschiedene Modellmethoden aufrufen.

Sie benötigen außerdem eine Reihe von Ansichten: eine Liste von Büchern, Informationen zu einem Buch, einen Warenkorb, eine Liste von Bestellungen. Jede Seite einer Webanwendung ist eigentlich eine separate Ansicht, die dem Benutzer einen bestimmten Aspekt des Modells anzeigt.

Sehen wir uns an, was passiert, wenn ein Benutzer eine Liste mit im Buchladen empfohlenen Büchern öffnet, um Titel anzuzeigen. Der gesamte Handlungsablauf lässt sich in Form von 6 Schritten beschreiben:

Schritte:

1. Der Benutzer klickt auf den Link „empfohlen“ und der Browser sendet eine Anfrage beispielsweise an /books/recommendations.
2. Der Controller prüft die Anfrage : Der Benutzer muss angemeldet sein. Oder wir sollten Büchersammlungen für nicht angemeldete Benutzer haben. Der Controller ruft dann das Modell auf und fordert es auf, die Liste der dem Benutzer N empfohlenen Bücher zurückzugeben.
3. Das Modell greift auf die Datenbank zu und ruft von dort Informationen über Bücher ab: Bücher, die derzeit beliebt sind, vom Benutzer gekaufte Bücher, von seinen Freunden gekaufte Bücher, Bücher von seiner Wunschliste. Basierend auf diesen Daten erstellt das Modell eine Liste mit 10 empfohlenen Büchern und sendet sie an den Controller zurück.
4. Der Verantwortliche erhält eine Liste empfohlener Bücher und schaut sich diese an. In dieser Phase trifft der Controller Entscheidungen! Wenn nur wenige Bücher vorhanden sind oder die Liste völlig leer ist, wird eine Liste mit Büchern für einen nicht angemeldeten Benutzer angefordert. Wenn gerade eine Werbeaktion läuft, kann der Controller Werbebücher zur Liste hinzufügen.
5. Der Controller bestimmt, welche Seite dem Benutzer angezeigt wird. Es kann eine Fehlerseite sein, eine Seite mit einer Liste von Büchern, eine Seite, die gratuliert, dass der Benutzer zum millionsten Besucher geworden ist.
6. Der Server stellt dem Client die vom Controller ausgewählte Seite ( Ansicht ) zur Verfügung. Es wird mit den notwendigen Daten (Benutzername, Bücherliste) gefüllt und geht an den Kunden.
7. Der Client empfängt die Seite und zeigt sie dem Benutzer an.

Welche Vorteile bietet dieser Ansatz?

Der offensichtlichste Vorteil, den wir durch die Verwendung des MVC-Konzepts erhalten, ist eine klare Trennung von Präsentationslogik (Benutzeroberfläche) und Anwendungslogik (Backend).

Der zweite Vorteil ist die Zweiteilung des Serverteils: ein Smart Model ( Executor ) und einen Controller ( Decision Center ).

Im vorherigen Beispiel gab es einen Moment, in dem der Controller eine leere Liste empfohlener Bücher vom Modell erhalten und entscheiden konnte, was damit geschehen soll. Theoretisch könnte diese Logik direkt in das Modell eingefügt werden.

Erstens würde das Modell bei der Anforderung empfohlener Bücher entscheiden, was zu tun ist, wenn die Liste leer ist. Dann müsste ich den Code an der gleichen Stelle hinzufügen, was zu tun ist, wenn jetzt eine Aktion läuft, dann mehr verschiedene Optionen.

Dann stellte sich heraus, dass der Shop-Administrator sehen wollte, wie die Seite des Benutzers ohne Werbung aussehen würde, oder umgekehrt, es gibt jetzt keine Werbung, aber er möchte sehen, wie die zukünftige Werbung angezeigt wird. Und dafür gibt es keine Methoden. Daher wurde beschlossen, das Entscheidungszentrum (Controller) von der Geschäftslogik (Modell) zu trennen.

Das MVC-Konzept isoliert nicht nur Ansichten von der Anwendungslogik, sondern reduziert auch die Komplexität großer Anwendungen erheblich. Der Code ist viel strukturierter, was die Wartung, das Testen und die Wiederverwendung von Lösungen erleichtert.

Wenn Sie das Konzept von MVC verstehen, erkennen Sie als Entwickler, wo Sie die Sortierung der Buchliste hinzufügen müssen:

• Auf Datenbankabfrageebene.
• Auf der Ebene der Geschäftslogik (Modell).
• Auf der Ebene der Geschäftslogik (Controller).
• Im Blick – auf der Client-Seite.

Und das ist keine rhetorische Frage. Überlegen Sie jetzt, wo und warum Sie den Code zum Sortieren der Bücherliste hinzufügen müssen.

Klassisches MVC-Modell

Die Interaktion zwischen MVC-Komponenten wird in Webanwendungen und mobilen Anwendungen unterschiedlich implementiert. Dies liegt daran, dass die Web-App nur von kurzer Dauer ist, eine Benutzeranfrage verarbeitet und beendet wird, während die mobile App viele Anfragen ohne Neustart verarbeitet.

Webanwendungen verwenden typischerweise das „passive“ Modell, während mobile Anwendungen das „aktive“ Modell verwenden. Das aktive Modell ermöglicht Ihnen im Gegensatz zum passiven Modell das Abonnieren und den Erhalt von Benachrichtigungen über Änderungen. Für Webanwendungen ist dies nicht erforderlich.

So sieht das Zusammenspiel der Komponenten in verschiedenen Modellen aus:

Mobile Anwendungen (aktives Modell) nutzen aktiv Ereignisse und den Ereignisabonnementmechanismus. Bei diesem Ansatz abonniert view ( view ) Modelländerungen. Wenn dann ein Ereignis eintritt (z. B. wenn der Benutzer auf eine Schaltfläche klickt), wird der Controller aufgerufen . Außerdem erhält das Modell einen Befehl zum Ändern der Daten.

Wenn sich einige Daten geändert haben, generiert das Modell ein Ereignis über die Änderung dieser Daten. Alle Ansichten, die dieses Ereignis abonniert haben (für das es wichtig ist, diese bestimmten Daten zu ändern), empfangen dieses Ereignis und aktualisieren die Daten in ihrer Schnittstelle.

Bei Webanwendungen sind die Dinge etwas anders organisiert. Der wesentliche technische Unterschied besteht darin, dass der Client keine serverseitigen Nachrichten auf Initiative des Servers empfangen kann .

Daher sendet ein Controller in einer Webanwendung normalerweise keine Nachrichten an die Ansicht, sondern gibt dem Client eine neue Seite, die technisch gesehen eine neue Ansicht oder sogar eine neue Clientanwendung ist (wenn eine Seite nichts über die andere weiß). .

Derzeit wird dieses Problem teilweise durch folgende Ansätze gelöst:

• Regelmäßige Abfrage des Servers auf Änderungen wichtiger Daten (mindestens einmal pro Minute).
• Mit WebSockets kann ein Client Servernachrichten abonnieren.
• Web-Push-Benachrichtigungen von der Serverseite.
• Das HTTP/2-Protokoll ermöglicht es dem Server, das Senden von Nachrichten an den Client zu initiieren.