Teil 7. Einführung in das MVC-Muster (Model-View-Controller).

Dieses Material ist Teil der Reihe „Einführung in die Unternehmensentwicklung“. Vorherige Artikel:

• zum Thema Networking
• über Softwarearchitektur
• über HTTP/HTTPS
• über die Grundlagen von Maven
• über Servlets (Schreiben einer einfachen Webanwendung)
• über Servlet-Container

In diesem Artikel lernen wir etwas namens MVC kennen. Wir sprechen darüber, was MVC ist, gehen auf seine Geschichte ein, erkunden die grundlegenden Ideen und Konzepte von MVC, schauen uns Schritt für Schritt an, wie man eine Anwendung in Model-, View- und Controller-Module aufteilt, schreiben ein Erstellen Sie eine kleine Webanwendung mit Spring Boot und sehen Sie am Beispiel von Spring MVC, wie Daten von Java-Code an HTML-Seiten gesendet werden. Um dieses Material zu verstehen, müssen Sie mit Designmustern vertraut sein, insbesondere mit Beobachter und Fassade. Machen Sie sich mit HTTP-Anfragen und -Antworten vertraut, verstehen Sie die Grundlagen von HTML und wissen Sie, was Java-Annotationen sind. Schnappen Sie sich eine Tasse Kaffee und einen Snack und machen Sie es sich bequem. Lass uns anfangen.

Geschichte von MVC

Die Ideen hinter MVC wurden von Trygve Reenskaug formuliert, als er Ende der 1970er Jahre bei Xerox PARC arbeitete. Damals erforderte die Arbeit mit Computern ein gewisses Maß an Wissen und das ständige Studium umfangreicher Dokumentationen. Die Aufgabe, die Reenskaug zusammen mit einer Gruppe sehr starker Entwickler löste, bestand darin, die Interaktion eines normalen Benutzers mit dem Computer zu vereinfachen. Es galt, Werkzeuge zu schaffen, die einerseits äußerst einfach und verständlich sind und andererseits die Steuerung von Computern und komplexen Anwendungen ermöglichen. Reenskaug arbeitete in einem Team, das unter der Leitung von Alan Kay einen Laptop „für Kinder jeden Alters“ entwickelte – das Dynabook – sowie die SmallTalk-Sprache. Damals wurden die Konzepte einer benutzerfreundlichen Schnittstelle festgelegt. In vieler Hinsicht, Die Arbeit von Reenskaug und seinem Team beeinflusste die Entwicklung der IT-Welt. Hier ist eine interessante Tatsache, die nicht direkt auf MVC zutrifft, aber die Bedeutung dieser Entwicklungen verdeutlicht. Alan Kaygenannt„Als ich 1984 zum ersten Mal bei Apple ankam, war der Mac bereits auf dem Markt und Newsweek kontaktierte mich und fragte mich, was ich von dem Mac halte. Ich sagte: ‚Nun, der Mac ist der erste Personal Computer, der gut genug ist kritisiert werden.' Nachdem er 2007 das iPhone angekündigt hatte, brachte er es zu mir und reichte es mir. Er sagte: „Alan, ist das gut genug, um kritisiert zu werden?“ Und ich sagte: ‚Steve, mach es so groß wie ein Tablet und du wirst die Welt beherrschen.‘“ Nach drei Jahren, am 27. Januar 2010, stellte Apple das iPad mit einer Diagonale von 9,7 Zoll vor. Mit anderen Worten: Steve Jobs folgte fast genau dem Rat von Alan Kay. Reenskaugs Projekt dauerte 10 Jahre. Doch nach weiteren 10 Jahren kam die erste Veröffentlichung über MVC ans Licht. Martin Fowler, Autor mehrerer Bücher und Artikel zum Thema Softwarearchitektur, erwähnt, dass er MVC mit einer funktionierenden Version von Smalltalk studiert hat. Da es lange Zeit keine Informationen über MVC aus der Originalquelle gab und aus mehreren anderen Gründen, gab es eine Vielzahl unterschiedlicher Interpretationen dieses Konzepts. Daher betrachten viele MVC als Designmuster. Seltener wird MVC als zusammengesetztes Muster oder als Kombination mehrerer Muster bezeichnet, die zusammenarbeiten, um komplexe Anwendungen zu erstellen. Aber wie bereits erwähnt, handelt es sich bei MVC in erster Linie um eine Reihe architektonischer Ideen/Prinzipien/Ansätze, die auf unterschiedliche Weise und mit unterschiedlichen Mustern umgesetzt werden können ... Als Nächstes betrachten wir die Hauptideen, die im MVC-Konzept verankert sind. und aus mehreren anderen Gründen erschien eine große Anzahl unterschiedlicher Interpretationen dieses Konzepts. Daher betrachten viele MVC als Designmuster. Seltener wird MVC als zusammengesetztes Muster oder als Kombination mehrerer Muster bezeichnet, die zusammenarbeiten, um komplexe Anwendungen zu erstellen. Aber wie bereits erwähnt, handelt es sich bei MVC in erster Linie um eine Reihe architektonischer Ideen/Prinzipien/Ansätze, die auf unterschiedliche Weise und mit unterschiedlichen Mustern umgesetzt werden können ... Als Nächstes betrachten wir die Hauptideen, die im MVC-Konzept verankert sind. und aus mehreren anderen Gründen erschien eine große Anzahl unterschiedlicher Interpretationen dieses Konzepts. Daher betrachten viele MVC als Designmuster. Seltener wird MVC als zusammengesetztes Muster oder als Kombination mehrerer Muster bezeichnet, die zusammenarbeiten, um komplexe Anwendungen zu erstellen. Aber wie bereits erwähnt, handelt es sich bei MVC in erster Linie um eine Reihe architektonischer Ideen/Prinzipien/Ansätze, die auf unterschiedliche Weise und mit unterschiedlichen Mustern umgesetzt werden können ... Als Nächstes betrachten wir die Hauptideen, die im MVC-Konzept verankert sind.

MVC: Grundlegende Ideen und Prinzipien

• VC ist eine Reihe architektonischer Ideen und Prinzipien zum Aufbau komplexer Informationssysteme mit einer Benutzeroberfläche
• MVC ist eine Abkürzung und steht für: Model-View-Controller

Haftungsausschluss: MVC ist kein Designmuster. MVC ist eine Reihe architektonischer Ideen und Prinzipien zum Aufbau komplexer Systeme mit einer Benutzeroberfläche. Der Einfachheit halber beziehen wir uns jedoch auf das MVC-Muster, um nicht immer wieder „eine Reihe von Architekturideen“ zu sagen. Beginnen wir mit dem Einfachen. Was verbirgt sich hinter den Worten Model-View-Controller? Wenn Sie das MVC-Muster zur Entwicklung von Systemen mit Benutzeroberfläche verwenden, müssen Sie das System in drei Komponenten unterteilen. Sie können auch Module oder Komponenten genannt werden. Nennen Sie sie wie Sie wollen, aber teilen Sie das System in drei Komponenten auf. Jede Komponente hat ihren eigenen Zweck. Modell. Die erste Komponente/das erste Modul wird als Modell bezeichnet. 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 durch die Ansicht generiert. Regler.Das dritte Glied in dieser Kette ist der Controller. Es enthält den Code, der für die Verarbeitung von Benutzeraktionen verantwortlich ist (alle Benutzeraktionen werden 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 darf. 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 Format bereitzustellen, das der Benutzer nutzen kann. Die Haupteinschränkung der Ansicht besteht darin, dass sie das Modell in keiner Weise ändern darf. Der Hauptzweck des Controllers besteht darin, Benutzeraktionen zu verarbeiten. Über den Controller nimmt der Benutzer Änderungen am Modell vor. Genauer gesagt, auf die Daten, die im Modell gespeichert sind. Hier ist das Diagramm, das Sie zuvor in der Lektion gesehen haben: Aus all dem können wir eine logische Schlussfolgerung ziehen. Ein komplexes System muss in Module unterteilt werden. Beschreiben wir kurz die Schritte, um diese Trennung zu erreichen.

Schritt 1: Trennen Sie die Geschäftslogik der Anwendung von der Benutzeroberfläche

Die Hauptidee von MVC besteht darin, dass jede Anwendung mit einer Benutzeroberfläche in zwei Module unterteilt werden kann: ein Modul, das für die Implementierung der Geschäftslogik verantwortlich ist, und die Benutzeroberfläche. Das erste Modul implementiert die Hauptfunktionalität der Anwendung. Dieses Modul ist der Kern des Systems, in dem das Domänenmodell der Anwendung implementiert wird. Im MVC-Paradigma ist dieses Modul der Buchstabe M, also das Modell. Das zweite Modul implementiert die gesamte Benutzeroberfläche, einschließlich der Logik zur Anzeige von Daten für den Benutzer und zur Abwicklung der Benutzerinteraktion mit der Anwendung. Das Hauptziel dieser Trennung besteht darin, sicherzustellen, dass der Kern des Systems (das „Modell“ in der MVC-Terminologie) unabhängig entwickelt und getestet werden kann. Nach dieser Trennung sieht die Architektur der Anwendung folgendermaßen aus:

Schritt 2 Nutzen Sie das Beobachtermuster, um das Modell noch unabhängiger zu machen und Benutzeroberflächen zu synchronisieren

Hier haben wir 2 Ziele:

1. Erreichen Sie eine noch größere Unabhängigkeit des Modells
2. Benutzeroberflächen synchronisieren

Das folgende Beispiel soll Ihnen helfen zu verstehen, was wir unter Synchronisierung von Benutzeroberflächen verstehen. Angenommen, wir kaufen online eine Kinokarte und sehen die Anzahl der verfügbaren Plätze im Kino. Zur gleichen Zeit kauft möglicherweise jemand anderes eine Kinokarte. Wenn diese andere Person vor uns eine Eintrittskarte kauft, würden wir uns wünschen, dass sich die Anzahl der verfügbaren Plätze für die von uns in Betracht gezogene Vorstellung verringert. Lassen Sie uns nun darüber nachdenken, wie dies innerhalb eines Programms umgesetzt werden kann. Angenommen, wir haben den Kern unseres Systems (unser Modell) und die Schnittstelle (die Webseite zum Ticketkauf). Zwei Benutzer versuchen gleichzeitig, einen Sitzplatz im Theater zu wählen. Der erste Benutzer kauft ein Ticket. Die Webseite muss dem zweiten Benutzer anzeigen, dass dies geschehen ist. Wie soll das passieren? Wenn wir die Schnittstelle vom Kern aus aktualisieren, dann hängt der Kern (unser Modell) von der Schnittstelle ab. Während wir das Modell entwickeln und testen, müssen wir die verschiedenen Möglichkeiten zur Aktualisierung der Schnittstelle berücksichtigen. Um dies zu erreichen, müssen wir das Beobachtermuster implementieren. Mit diesem Muster kann das Modell Änderungsbenachrichtigungen an alle Listener senden. Als Ereignis-Listener (oder Beobachter) empfängt die Benutzeroberfläche Benachrichtigungen und wird aktualisiert. Einerseits ermöglicht das Beobachtermuster dem Modell, die Schnittstelle (Ansicht und Controller) darüber zu informieren, dass Änderungen stattgefunden haben, ohne dass es tatsächlich etwas darüber weiß, und bleibt so unabhängig. Andererseits ermöglicht es die Synchronisierung von Benutzeroberflächen. Wir müssen das Beobachtermuster implementieren. Mit diesem Muster kann das Modell Änderungsbenachrichtigungen an alle Listener senden. Als Ereignis-Listener (oder Beobachter) empfängt die Benutzeroberfläche Benachrichtigungen und wird aktualisiert. Einerseits ermöglicht das Beobachtermuster dem Modell, die Schnittstelle (Ansicht und Controller) darüber zu informieren, dass Änderungen stattgefunden haben, ohne dass es tatsächlich etwas darüber weiß, und bleibt so unabhängig. Andererseits ermöglicht es die Synchronisierung von Benutzeroberflächen. Wir müssen das Beobachtermuster implementieren. Mit diesem Muster kann das Modell Änderungsbenachrichtigungen an alle Listener senden. Als Ereignis-Listener (oder Beobachter) empfängt die Benutzeroberfläche Benachrichtigungen und wird aktualisiert. Einerseits ermöglicht das Beobachtermuster dem Modell, die Schnittstelle (Ansicht und Controller) darüber zu informieren, dass Änderungen stattgefunden haben, ohne dass es tatsächlich etwas darüber weiß, und bleibt so unabhängig. Andererseits ermöglicht es die Synchronisierung von Benutzeroberflächen.

Schritt 3 Trennen Sie die Schnittstelle in Ansicht und Controller

Wir unterteilen die Anwendung weiterhin in Module, jetzt jedoch auf einer niedrigeren Ebene in der Hierarchie. In diesem Schritt wird die Benutzeroberfläche (die wir in Schritt 1 in ein eigenes Modul unterteilt haben) in eine Ansicht und einen Controller aufgeteilt. Es ist schwierig, eine strikte Grenze zwischen der Ansicht und dem Controller zu ziehen. Wenn wir sagen, dass die Ansicht das ist, was der Benutzer sieht, und der Controller der Mechanismus ist, der es dem Benutzer ermöglicht, mit dem System zu interagieren, könnten Sie auf einen Widerspruch hinweisen. Bedienelemente, wie zum Beispiel Schaltflächen auf einer Webseite oder eine virtuelle Tastatur auf dem Bildschirm eines Telefons, sind grundsätzlich Teil des Controllers. Sie sind für den Benutzer jedoch genauso sichtbar wie jeder andere Teil der Ansicht. Worüber wir hier wirklich reden, ist funktionale Trennung. Die Hauptaufgabe der Benutzeroberfläche besteht darin, die Interaktion des Benutzers mit dem System zu erleichtern.

• Systeminformationen ausgeben und dem Benutzer komfortabel anzeigen
• Benutzerdaten und Befehle eingeben (dem System mitteilen)

Diese Funktionen legen fest, wie die Benutzeroberfläche in Module unterteilt werden soll. Am Ende sieht die Systemarchitektur so aus: Und so kommen wir zu einer Anwendung, die aus drei Modulen namens Model, View und Controller besteht. Fassen wir zusammen:

1. Nach den Prinzipien des MVC-Paradigmas muss ein System in Module unterteilt werden.
2. Das wichtigste und unabhängigste Modul sollte das Modell sein.
3. Das Modell ist der Kern des Systems. Es sollte möglich sein, es unabhängig von der Benutzeroberfläche zu entwickeln und zu testen.
4. Um dies zu erreichen, müssen wir im ersten Schritt der Teilung das System in ein Modell und eine Benutzeroberfläche aufteilen.
5. Anschließend stärken wir mithilfe des Beobachtermusters die Unabhängigkeit des Modells und synchronisieren Benutzeroberflächen.
6. Der dritte Schritt besteht darin, die Benutzeroberfläche in einen Controller und eine Ansicht zu unterteilen.
7. Alles, was zum Empfangen von Benutzerdaten in das System erforderlich ist, befindet sich im Controller.
8. Alles, was zur Bereitstellung von Informationen an den Benutzer erforderlich ist, befindet sich in der Ansicht.

Nur noch eine wichtige Sache, die Sie besprechen sollten, bevor Sie Ihre heiße Schokolade trinken können.

Ein wenig darüber, wie die Ansicht und der Controller mit dem Modell interagieren

Durch die Eingabe von Informationen über den Controller ändert der Benutzer das Modell. Oder zumindest ändert der Benutzer die Modelldaten. Wenn der Benutzer Informationen über Schnittstellenelemente (über die Ansicht) erhält, erhält er Informationen über das Modell. Wie kommt es dazu? Auf welche Weise interagieren die Ansicht und der Controller mit dem Modell? Schließlich können die Klassen der Ansicht die Methoden der Modellklassen nicht direkt aufrufen, um Daten zu lesen/schreiben. Andernfalls könnten wir nicht sagen, dass das Modell unabhängig ist. Das Modell besteht aus einer Reihe eng verwandter Klassen, auf die weder die Ansicht noch der Controller Zugriff haben sollten. Um das Modell mit der Ansicht und dem Controller zu verbinden, müssen wir das Fassadenentwurfsmuster implementieren. Die Fassade des Modells ist die Schicht zwischen dem Modell und der Benutzeroberfläche. Dadurch erhält die Ansicht bequem formatierte Daten und der Controller ändert Daten, indem er die erforderlichen Methoden an der Fassade aufruft. Am Ende sieht alles so aus:

MVC: Was gewinnen wir?

Das Hauptziel des MVC-Paradigmas besteht darin, die Implementierung der Geschäftslogik (das Modell) von ihrer Visualisierung (der Ansicht) zu trennen. Diese Trennung erhöht die Möglichkeiten zur Wiederverwendung von Code. Die Vorteile von MVC zeigen sich am deutlichsten, wenn wir dieselben Daten in verschiedenen Formaten darstellen müssen. Zum Beispiel als Tabelle, Grafik oder Diagramm (mit verschiedenen Ansichten). Gleichzeitig können wir, ohne die Art und Weise zu beeinflussen, wie Ansichten implementiert werden, ändern, wie wir auf Benutzeraktionen (Schaltflächenklicks, Dateneingabe) reagieren. Wenn Sie die Prinzipien von MVC befolgen, können Sie die Softwareentwicklung vereinfachen, die Lesbarkeit des Codes verbessern und die Erweiterbarkeit und Wartbarkeit verbessern. Im letzten Artikel der Reihe „Einführung in die Unternehmensentwicklung“ werden wir uns eine MVC-Implementierung ansehen, die mit Spring MVC erstellt wurde. Teil 8. Schreiben wir eine kleine Anwendung mit Spring Boot