In diesem Material stellen wir Ihnen so etwas wie MVC vor. Lassen Sie uns darüber sprechen, was MVC ist, gehen wir auf die Entstehungsgeschichte ein, verstehen wir die wichtigsten Ideen und Konzepte von MVC, überlegen wir Schritt für Schritt, wie man eine Anwendung in Model-, View- und Controller-Module aufteilt und schreiben wir auch eine kleine Webanwendung Spring-Boot und am Beispiel von Spring-MVC sehen wir uns an, wie Daten von Java-Code auf HTML-Seiten übertragen werden. Um dieses Material zu verstehen, müssen Sie mit Designmustern vertraut sein, insbesondere mit Observer und Facade. Machen Sie sich mit HTTP-Anfragen und -Antworten vertraut, verstehen Sie die Grundlagen von HTML und wissen Sie, was Annotationen in Java sind. Lehnen Sie sich zurück, kochen Sie Tee, bereiten Sie Dessert, Salat, Hauptgericht und ersten Gang zu. Wir beginnen.
Geschichte von MVC
Die Ideen für MVC wurden von Trygve Reenskaug formuliert, als er Ende der 70er Jahre bei Xerox PARC arbeitete. Damals war die Arbeit am Computer ohne einen akademischen Abschluss und das ständige Studium umfangreicher Dokumentationen nicht mehr wegzudenken. Das Problem, das Reenskaug gemeinsam mit einer Gruppe sehr starker Entwickler löste, bestand darin, die Interaktion des Durchschnittsbenutzers mit einem Computer zu vereinfachen. Es galt, Tools zu schaffen, die einerseits äußerst einfach und verständlich sind und andererseits die Verwaltung eines Computers und komplexer Anwendungen ermöglichen. Reenskaug arbeitete im Team, das den tragbaren Computer „für Kinder jeden Alters“ – Dynabook – sowie die SmallTalk-Sprache unter der Leitung von Alan Kay entwickelte. Damals und dort wurden die Konzepte einer benutzerfreundlichen Schnittstelle festgelegt. Reenskaugs Arbeit mit seinem Team hatte großen Einfluss auf die Entwicklung des IT-Bereichs. Lassen Sie uns eine interessante Tatsache vorstellen, die nicht direkt mit MVC zusammenhängt, aber die Bedeutung dieser Entwicklungen verdeutlicht. Im Jahr 2007, nach der Präsentation des Apple iPhone, sagte Alan Kay: „Als der Macintosh herauskam, fragte Newsweek, was ich davon halte.“ Ich sagte: Das ist der erste Personal Computer, der Kritik verdient. Nach der Präsentation kam Steve Jobs und fragte: Ist das iPhone kritikwürdig? Und ich sagte: Machen Sie es fünf mal acht Zoll groß, und Sie werden die Welt erobern.“ Drei Jahre später, am 27. Januar 2010, stellte Apple das 9,7-Zoll-iPad vor. Das heißt, Steve Jobs folgte Alan Kays Rat fast wörtlich. Das Projekt, an dem Rennskaug arbeitete, dauerte 10 Jahre. Und die erste Veröffentlichung über MVC von seinen Machern wurde weitere 10 Jahre später veröffentlicht. Martin Fowler, Autor einer Reihe von Büchern und Artikeln über Softwarearchitektur, erwähnt, dass er MVC aus einer funktionierenden Version von SmallTalk gelernt hat. Da es lange Zeit keine Informationen über MVC aus der Primärquelle gab, sowie aus einer Reihe anderer Gründe, ist eine Vielzahl unterschiedlicher Interpretationen dieses Konzepts aufgetaucht. Aus diesem Grund betrachten viele Menschen MVC als ein Designschema oder -muster. Seltener wird MVC als zusammengesetztes Muster oder als Kombination mehrerer Muster bezeichnet, die zusammenarbeiten, um komplexe Anwendungen zu implementieren. Tatsächlich handelt es sich bei MVC jedoch, wie bereits erwähnt, in erster Linie um eine Reihe architektonischer Ideen/Prinzipien/Ansätze, die auf unterschiedliche Weise und mit verschiedenen Mustern umgesetzt werden können. Als Nächstes werden wir versuchen, einen Blick auf die Hauptideen zu werfen, die im MVC-Konzept verankert sind.
Was ist MVC: Grundideen und Prinzipien
VC ist eine Reihe architektonischer Ideen und Prinzipien zum Aufbau komplexer Informationssysteme mit einer Benutzeroberfläche;
MVC ist ein Akronym, das für Model-View-Controller steht.
Haftungsausschluss: MVC ist kein Designmuster. Bei MVC handelt es sich genau um eine Reihe architektonischer Ideen und Prinzipien zum Aufbau komplexer Systeme mit einer Benutzeroberfläche. Der Einfachheit halber nennen wir MVC jedoch ein Muster, um nicht jedes Mal zu wiederholen: „Eine Reihe architektonischer Ideen ...“. Beginnen wir mit etwas Einfachem. Was verbirgt sich hinter den Worten Model-View-Controller? Wenn Sie Systeme mit einer Benutzeroberfläche nach dem MVC-Muster entwickeln, müssen Sie das System in drei Komponenten unterteilen. Diese wiederum können als Module oder Komponenten bezeichnet werden. Sagen Sie, was Sie wollen, aber teilen Sie durch drei. Jede Komponente hat ihren eigenen Zweck. Modell. Die erste Komponente/Modul ist das sogenannte Modell. Es enthält die gesamte Geschäftslogik der Anwendung. Sicht. Der zweite Teil des Systems ist die Ansicht. Dieses Modul ist für die Anzeige von Daten für den Benutzer verantwortlich. Alles, was der Benutzer sieht, wird von der Ansicht generiert. Regler. Das dritte Glied in dieser Kette ist der Controller. Es speichert Code, der für die Verarbeitung von Benutzeraktionen verantwortlich ist (jede Benutzeraktion im System wird im Controller verarbeitet). Das Modell ist der unabhängigste Teil des Systems. So unabhängig, dass es nichts über die View- und Controller-Module wissen sollte. Das Modell ist so unabhängig, dass seine Entwickler möglicherweise praktisch nichts über die Ansicht und den Controller wissen. Der Hauptzweck der Ansicht besteht darin, Informationen aus dem Modell in einem benutzerfreundlichen Format bereitzustellen. Die Haupteinschränkung der Ansicht besteht darin, dass sie das Modell in keiner Weise ändern sollte. Der Hauptzweck des Controllers besteht darin, Benutzeraktionen zu verarbeiten. Über den Controller nimmt der Benutzer Änderungen am Modell vor. Genauer gesagt, in die Daten, die im Modell gespeichert sind. Lassen Sie uns noch einmal das Diagramm wiedergeben, das Ihnen bereits in der Vorlesung gezeigt wurde: Aus all dem können wir eine völlig logische Schlussfolgerung ziehen. Ein komplexes System muss in Module unterteilt werden. Lassen Sie uns kurz die Schritte beschreiben, wie eine solche Trennung erreicht werden kann.
Schritt 1: Trennen Sie die Geschäftslogik der Anwendung von der Benutzeroberfläche
Die Kernidee von MVC besteht darin, dass jede Anwendung mit einer Benutzeroberfläche in erster Näherung in zwei Module unterteilt werden kann: ein Modul, das für die Implementierung der Geschäftslogik der Anwendung verantwortlich ist, und eine Benutzeroberfläche. Das erste Modul implementiert die Hauptfunktionalität der Anwendung. Dieses Modul wird den Kern des Systems bilden, in dem das Anwendungsdomänenmodell implementiert wird. Im MVC-Konzept wird dieses Modul unser Buchstabe M sein, d. h. Modell. Das zweite Modul implementiert die gesamte Benutzeroberfläche, einschließlich der Anzeige von Daten für den Benutzer und der Logik der Benutzerinteraktion mit der Anwendung. Der Hauptzweck dieser Trennung besteht darin, sicherzustellen, dass der Kern des Systems (Modell in der MVC-Terminologie) unabhängig entwickelt und getestet werden kann. Die Anwendungsarchitektur nach einer solchen Aufteilung sieht folgendermaßen aus:
Schritt 2. Erreichen Sie mithilfe des Observer-Musters eine noch größere Unabhängigkeit des Modells sowie eine Synchronisierung der Benutzeroberflächen
Dabei verfolgen wir 2 Ziele:
Erreichen Sie eine noch größere Unabhängigkeit vom Modell.
Benutzeroberflächen synchronisieren.
Das folgende Beispiel soll Ihnen helfen zu verstehen, was unter der Synchronisierung von Benutzeroberflächen zu verstehen ist. Nehmen wir an, wir kaufen online eine Kinokarte und sehen die Anzahl der verfügbaren Plätze im Kino. Jemand anderes kann gleichzeitig mit uns eine Kinokarte kaufen. Wenn dieser Jemand vor uns ein Ticket kauft, würden wir gerne sehen, dass die Anzahl der verfügbaren Plätze für unsere Sitzung gesunken ist. Lassen Sie uns nun darüber nachdenken, wie dies im Programm implementiert werden kann. Nehmen wir an, wir haben einen Systemkern (unser Modell) und eine Schnittstelle (die Webseite, auf der wir einen Kauf tätigen). Auf der Website wählen 2 Benutzer gleichzeitig einen Sitzplatz aus. Der erste Benutzer hat ein Ticket gekauft. Der zweite Benutzer muss diese Informationen auf der Seite anzeigen. Wie soll das passieren? Wenn wir die Schnittstelle vom Systemkernel aktualisieren, ist unser Kernel, unser Modell, von der Schnittstelle abhängig. Beim Entwickeln und Testen eines Modells müssen Sie verschiedene Möglichkeiten zur Aktualisierung der Schnittstelle berücksichtigen. Um dies zu erreichen, müssen Sie das Observer-Muster implementieren. Mit seiner Hilfe sendet das Modell Benachrichtigungen über Änderungen an alle Abonnenten. Als solcher Abonnent erhält die Schnittstelle eine Benachrichtigung und Aktualisierung. Das Observer-Muster ermöglicht es dem Modell einerseits, die Schnittstelle (Ansicht und Controller) darüber zu informieren, dass darin Änderungen aufgetreten sind, und andererseits tatsächlich nichts darüber zu „wissen“ und dadurch unabhängig zu bleiben. Andererseits wird dadurch eine Synchronisierung der Benutzeroberflächen ermöglicht.
Schritt 3. Aufteilen der Schnittstelle in View und Controller
Wir unterteilen die Anwendung weiterhin in Module, jedoch auf einer niedrigeren Ebene der Hierarchie. In diesem Schritt wird die Benutzeroberfläche (die in Schritt 1 in ein separates Modul aufgeteilt wurde) in eine Ansicht und einen Controller unterteilt. Es ist schwierig, eine strikte Grenze zwischen einer Ansicht und einem Controller zu ziehen. Wenn wir sagen, dass die Ansicht das ist, was der Benutzer sieht, und der Controller der Mechanismus ist, über den der Benutzer mit dem System interagieren kann, liegt ein gewisser Widerspruch vor. Steuerelemente wie Schaltflächen auf einer Webseite oder eine virtuelle Tastatur auf einem Telefonbildschirm sind im Wesentlichen Teil eines Controllers. Sie sind für den Benutzer jedoch genauso sichtbar wie jeder andere Teil der Ansicht. Hier sprechen wir eher über funktionale Aufteilung. Die Hauptaufgabe der Benutzeroberfläche besteht darin, die Interaktion des Benutzers mit dem System sicherzustellen. Das bedeutet, dass die Schnittstelle nur 2 Funktionen hat:
dem Benutzer Informationen über das System anzeigen und bequem anzeigen;
Benutzerdaten und Befehle in das System eingeben (an das System übermitteln);
Diese Funktionen legen fest, wie die Schnittstelle in Module unterteilt werden soll. Infolgedessen sieht die Systemarchitektur wie folgt aus: Wir haben also eine Anwendung aus drei Modulen namens Model, View und Controller. Zusammenfassen:
Den Prinzipien von MVC folgend muss das System in Module unterteilt werden.
Das wichtigste und unabhängigste Modul sollte das Modell sein.
Das Modell ist der Kern des Systems. Sie benötigen die Fähigkeit, es unabhängig von der Schnittstelle zu entwickeln und zu testen.
Dazu müssen Sie im ersten Schritt der Systemtrennung das System in ein Modell und eine Schnittstelle unterteilen.
Als nächstes stärken wir mithilfe des Observer-Musters das Modell in seiner Unabhängigkeit und erreichen eine Synchronisierung der Benutzeroberflächen.
Der dritte Schritt besteht darin, die Schnittstelle in einen Controller und eine Ansicht zu unterteilen.
Um Informationen vom Benutzer in das System einzugeben, ist lediglich die Eingabe in die Steuerung erforderlich.
Alles, was Informationen vom System an den Benutzer ausgibt, ist im Blick.
Es gibt noch eine wichtige Sache zu besprechen und Sie können Kakao trinken.
Ein wenig über die Beziehung zwischen der Ansicht und dem Controller und dem Modell
Wenn der Benutzer Informationen über die Steuerung eingibt, nimmt er dadurch Änderungen am Modell vor. Zumindest nimmt der Benutzer Änderungen an den Modelldaten vor. Wenn der Benutzer Informationen über Schnittstellenelemente (über die Ansicht) erhält, erhält er Informationen über die Modelldaten. Wie kommt es dazu? Wie interagieren View und Controller mit dem Modell? Schließlich kann es nicht sein, dass die View-Klassen direkt die Methoden der Model-Klassen zum Lesen/Schreiben von Daten nutzen, sonst kann von einer Unabhängigkeit des Models keine Rede sein. Das Modell stellt einen eng miteinander verbundenen Satz von Klassen dar, auf die weder die Ansicht noch der Controller Zugriff haben sollten. Um das Modell mit der Ansicht und dem Controller zu verbinden, ist es notwendig, das Fassadenentwurfsmuster zu implementieren. Die Modellfassade ist die eigentliche Ebene zwischen dem Modell und der Schnittstelle, über die die Ansicht Daten in einem geeigneten Format empfängt und der Controller die Daten durch Aufrufen der erforderlichen Fassadenmethoden ändert. Schematisch sieht am Ende alles so aus:
MVC: Was ist der Vorteil?
Das Hauptziel der Befolgung der MVC-Prinzipien besteht darin, die Implementierung der Geschäftslogik (Modell) der Anwendung von ihrer Visualisierung (Ansicht) zu trennen. Durch diese Trennung wird die Wiederverwendung von Code erhöht. Die Vorteile der Verwendung von MVC liegen am deutlichsten in Fällen, in denen der Benutzer dieselben Daten in unterschiedlichen Formen bereitstellen muss. Zum Beispiel in Form einer Tabelle, eines Diagramms oder eines Diagramms (unter Verwendung verschiedener Typen). Gleichzeitig können Sie, ohne die Implementierung von Ansichten zu beeinträchtigen, die Reaktionen auf Benutzeraktionen (Klick auf eine Schaltfläche, Eingabe von Daten) ändern. Wenn Sie den Prinzipien von MVC folgen, können Sie das Schreiben von Programmen vereinfachen, die Lesbarkeit des Codes erhöhen und die zukünftige Erweiterung und Wartung des Systems erleichtern. Im Abschlussmaterial der Reihe „Einführung in die Unternehmensentwicklung“ werden wir uns die Implementierung von MVC am Beispiel von Spring-MVC ansehen. Teil 8. Eine kleine Anwendung in Spring-Boot schreiben
Aus all dem können wir eine völlig logische Schlussfolgerung ziehen. Ein komplexes System muss in Module unterteilt werden. Lassen Sie uns kurz die Schritte beschreiben, wie eine solche Trennung erreicht werden kann.
Wir haben also eine Anwendung aus drei Modulen namens Model, View und Controller. Zusammenfassen:
GO TO FULL VERSION