MVC Framework

MVC steht für Model View Controller, was eine Abkürzung für Model-View-Controller ist. Es ist ein weit verbreitetes Software-Designparadigma. Die Kernidee besteht darin, den Code zu organisieren, indem die Geschäftslogik, die Daten und die Schnittstellenanzeige getrennt und die Geschäftslogik in einer Komponente zentralisiert werden. Auf diese Weise ist es bei der Verbesserung und Anpassung der Schnittstelle und der Benutzerinteraktion nicht erforderlich, die Geschäftslogik neu zu schreiben. MVC hat sich in einzigartiger Weise entwickelt, um die traditionellen Eingabe-, Verarbeitungs- und Ausgabefunktionen in eine logische grafische Benutzeroberflächenstruktur abzubilden.

MVC Programmiermuster

MVC ist ein Muster zum Erstellen von Webanwendungen unter Verwendung des MVC-Designs (Model View Controller model-view-controller). Die spezifische Einführung ist wie folgt:

+-------------------+
| Model |
| Der Kern der Anwendung, wie z.B. |
| die Datenbank usw., ist verantwortlich für |
| die Verarbeitung von Datenlogik und |
| den Zugriff und die Speicherung von Daten |
+-------------------+
 |
 |
 ▼
+-------------------+
| View |
| Anzeigeeffekte, wie z.B. |
| HTML-Seiten usw. |
| Erstellen von Anzeigeinhalten basierend auf Modelldaten |
+-------------------+
 |
 | Benutzerinteraktion
 ▲
+-------------------+
| Controller |
| Eingabe verarbeiten, einschließlich |
| Geschäftslogik, und ist verantwortlich für |
| das Lesen von Daten aus der View, |
| das Steuern der Benutzereingabe, |
| und das Senden von Daten an das Model |
+-------------------+

• Model: Repräsentiert den Kern der Anwendung, wie z.B. die Datenbank usw. Es ist hauptsächlich für die Bearbeitung der Datenlogik der Anwendung zuständig. Modellobjekte übernehmen in der Regel die Aufgabe, Daten in der Datenbank abzurufen und zu speichern.
• View: Wird für Anzeigeeffekte verwendet, wie z.B. gängige HTML-Seiten usw. Die View wird im Allgemeinen auf der Grundlage von Modelldaten erstellt.
• Controller: Behandelt die Benutzerinteraktion, ist in der Regel dafür zuständig, Daten aus der View zu lesen, die Benutzereingabe zu steuern und Daten an das Model zu senden.

Das MVC-Muster bietet auch die vollständige Kontrolle über HTML, CSS und JavaScript.

Vorteile

1. Geringe Kopplung: Die View-Schicht und die Business-Schicht sind getrennt, was bedeutet, dass beim Ändern des View-Schicht-Codes der Modell- und Controller-Code nicht neu kompiliert werden muss. Ähnlich verhält es sich, wenn sich der Geschäftsprozess oder die Geschäftsregeln der Anwendung ändern, muss nur die Modellschicht des MVC geändert werden. Da das Modell vom Controller und der View getrennt ist, ist es einfach, die Datenschicht und die Geschäftsregeln der Anwendung anzupassen. Wenn Sie beispielsweise die Datenbank von MySQL auf Oracle migrieren oder von einer RDBMS-Datenquelle auf LDAP umsteigen möchten, müssen Sie nur den Modellteil ändern. Sobald das Modell korrekt implementiert ist, kann die View die entsprechenden Daten korrekt anzeigen, unabhängig davon, ob die Datenquelle eine Datenbank oder ein LDAP-Server ist. Da die drei Komponenten einer MVC-Anwendung unabhängig voneinander sind, wirkt sich die Änderung einer Komponente nicht auf die anderen beiden aus. Daher kann auf dieser Designidee ein gut entkoppeltes System aufgebaut werden.
2. Hohe Wiederverwendbarkeit: Mit der Entwicklung der Technologie besteht die Notwendigkeit, auf die Anwendung auf verschiedene Arten zuzugreifen. Das MVC-Muster ermöglicht es verschiedenen Arten von Views, auf denselben serverseitigen Code zuzugreifen, da sich mehrere Views ein Modell teilen können, einschließlich jedes WEB-Browsers (HTTP) oder Wireless-Browsers (WAP). Benutzer können beispielsweise ein bestimmtes Produkt über einen Computer oder ein Mobiltelefon bestellen. Obwohl die Bestellmethoden unterschiedlich sind, ist die Geschäftslogik für die Bearbeitung der Produktbestellung dieselbe. Da die vom Modell zurückgegebenen Daten nicht formatiert sind, kann dieselbe Komponente von verschiedenen Schnittstellen verwendet werden. Beispielsweise können viele Daten in HTML oder WAP dargestellt werden. Die Operationen, die erforderlich sind, um diese unterschiedlichen Darstellungen zu erreichen, bestehen lediglich darin, die Implementierungsmethode der View-Schicht zu ändern, und die Steuerungsschicht und die Modellschicht müssen überhaupt nicht geändert werden. Da die Daten und Geschäftsregeln von der Präsentationsschicht getrennt wurden, kann der Code maximal wiederverwendet werden. Das Modell verfügt auch über die Funktionen der Zustandsverwaltung und der Datenpersistenzverarbeitung. Beispielsweise können der sitzungsbasierte Warenkorb und der E-Commerce-Prozess auch von Flash-Websites oder drahtlosen vernetzten Anwendungen wiederverwendet werden.
3. Niedrige Lebenszykluskosten: MVC reduziert den technischen Inhalt der Entwicklung und Wartung der Benutzeroberfläche.
4. Schnelle Bereitstellung: Die Verwendung des MVC-Musters reduziert die Entwicklungszeit erheblich. Es ermöglicht Programmierern (Java-Entwicklern), sich auf die Geschäftslogik zu konzentrieren, und Schnittstellenprogrammierern (HTML- und JSP-Entwicklern), sich auf die Präsentation zu konzentrieren.
5. Hohe Wartbarkeit: Die Trennung der View-Schicht und der Geschäftslogik-Schicht erleichtert auch die Wartung und Modifizierung von Webanwendungen.
6. Vorteilhaft für das Software-Engineering-Management: Da verschiedene Schichten ihre jeweiligen Funktionen ausführen, haben verschiedene Anwendungen in jeder Schicht bestimmte gemeinsame Merkmale, was für die Verwaltung von Programmcode durch Engineering und Tooling von Vorteil ist. Der Controller bietet auch den Vorteil, dass er verwendet werden kann, um verschiedene Modelle und Views zu verbinden, um Benutzeranforderungen zu erfüllen. Auf diese Weise kann der Controller ein leistungsstarkes Mittel zum Erstellen von Anwendungen bereitstellen. Angesichts einiger wiederverwendbarer Modelle und Views kann der Controller das Modell zur Verarbeitung gemäß den Benutzeranforderungen auswählen und dann die View auswählen, um dem Benutzer die Verarbeitungsergebnisse anzuzeigen.

Nachteile

1. Keine klare Definition: Es ist nicht einfach, MVC vollständig zu verstehen. Die Verwendung von MVC erfordert eine sorgfältige Planung. Da seine internen Prinzipien relativ komplex sind, braucht es einige Zeit, um darüber nachzudenken. Gleichzeitig bringt die strikte Trennung von Modell und View auch gewisse Schwierigkeiten beim Debuggen der Anwendung mit sich. Jede Komponente muss vor der Verwendung gründlich getestet werden.
2. Nicht geeignet für kleine und mittelgroße Anwendungen: Viel Zeit damit zu verbringen, MVC auf Anwendungen anzuwenden, die nicht sehr groß sind, ist die Mühe oft nicht wert.
3. Erhöht die Komplexität der Systemstruktur und -implementierung: Für einfache Schnittstellen erhöht das strikte Befolgen von MVC und das Trennen von Modell, View und Controller die Komplexität der Struktur und kann zu viele Aktualisierungsoperationen erzeugen, was die Betriebseffizienz verringert.
4. Zu enge Verbindung zwischen der View und dem Controller: Die View und der Controller sind separate, aber eng miteinander verbundene Komponenten. Die Anwendung der View ist ohne das Vorhandensein des Controllers sehr begrenzt, und umgekehrt. Dies behindert ihre unabhängige Wiederverwendung.
5. Ineffizienter Zugriff auf Modelldaten durch die View: Abhängig von der Bedienoberfläche des Modells muss die View möglicherweise mehrmals aufgerufen werden, um genügend Anzeigedaten zu erhalten. Unnötig häufiger Zugriff auf unveränderte Daten beeinträchtigt auch die Betriebsleistung.
6. Allgemeine erweiterte Schnittstellen-Tools oder -Konstruktoren unterstützen das Muster nicht: Die Kosten für die Transformation dieser Tools zur Anpassung an MVC und die Einrichtung separater Komponenten sind hoch, was zu Schwierigkeiten bei der Verwendung von MVC führt.

MVP-Muster

Vollständiger Name: Model-View-Presenter. MVP hat sich aus dem klassischen MVC-Muster entwickelt. Ihre grundlegenden Ideen sind ähnlich, d.h. der Controller/Presenter ist für die logische Verarbeitung zuständig, das Model stellt Daten bereit, und die View ist für die Anzeige zuständig.

+-------------------+
| Model |
| Daten bereitstellen und für |
| die Verarbeitung datenbezogener Logik verantwortlich sein |
+-------------------+
 |
 | Daten bereitstellen
 ▼
+-------------------+
| View |
| Daten anzeigen, der Benutzeroberflächenteil |
+-------------------+
 |
 | Benutzerinteraktion
 ▲
+-------------------+
| Presenter |
| Logik verarbeiten, zwischen dem Modell interagieren |
| und der View, und den Datenfluss koordinieren |
+-------------------+

Vorteile

1. Vollständige Trennung des Modells und der View: Wir können die View ändern, ohne das Modell zu beeinflussen.
2. Effizientere Nutzung des Modells: Da alle Interaktionen an einem Ort stattfinden - im Presenter.
3. Hohe Wiederverwendbarkeit: Wir können einen Presenter für mehrere Views verwenden, ohne die Logik des Presenters zu ändern. Diese Funktion ist sehr nützlich, da sich die View häufiger ändert als das Modell.
4. Einfache Testbarkeit: Wenn wir die Logik in den Presenter legen, können wir diese Logiken (Unit-Tests) ohne die Benutzeroberfläche testen.

Nachteile

Da das Rendering der View im Presenter platziert wird, ist die Interaktion zwischen der View und dem Presenter zu häufig. Es sollte auch verstanden werden, dass, wenn der Presenter die View zu stark rendert, dies oft seine Verbindung zu einer bestimmten View zu eng macht. Sobald die View geändert werden muss, muss auch der Presenter geändert werden. Wenn der Presenter beispielsweise ursprünglich verwendet wurde, um Html darzustellen, muss er jetzt auch verwendet werden, um Pdf darzustellen, dann muss die View wahrscheinlich auch geändert werden.

Unterschiede zwischen MVP und MVC

Als neues Muster hat MVP einen значни significant Unterschied zu MVC: In MVP verwendet die View das Modell nicht direkt. Die Kommunikation zwischen ihnen erfolgt über den Presenter (der Controller in MVC), und alle Interaktionen finden innerhalb des Presenters statt. In MVC liest die View Daten direkt aus dem Modell und nicht über den Controller.

In MVC kann die View direkt auf das Modell zugreifen. Infolgedessen enthält die View Modellinformationen und unvermeidlich auch einige Geschäftslogik. Im MVC-Modell wird mehr Aufmerksamkeit auf die Änderung des Modells gelegt, und es gibt mehrere verschiedene Anzeigen des Modells gleichzeitig, d.h. die View. Daher hängt im MVC-Modell das Modell nicht von der View ab, sondern die View hängt vom Modell ab. Da außerdem einige Geschäftslogik in der View implementiert ist, ist es schwieriger, die View zu ändern, und zumindest diese Geschäftslogiken können nicht wiederverwendet werden.

Obwohl die View in MVC tatsächlich auf das Modell "zugreifen" kann, empfehlen wir nicht, sich in der View auf das Modell zu verlassen. Stattdessen verlangen wir, dass die gesamte Geschäftslogik so weit wie möglich im Controller verarbeitet wird und die View nur mit dem Controller interagiert.

Die Unterschiede sind in der folgenden Abbildung dargestellt (hier können Sie sich auf die Originalbilder mvc.png und mvp.png beziehen, die Sie bereitgestellt haben):

MVVM-Framework

MVVM ist die Abkürzung für Model-View-ViewModel. Es ist im Wesentlichen eine verbesserte Version von MVC. MVVM abstrahiert den Zustand und das Verhalten der View, sodass wir die View-UI und die Geschäftslogik trennen können. Natürlich hat das ViewModel dies bereits für uns erledigt. Es kann die Daten des Modells extrahieren und gleichzeitig helfen, die Geschäftslogik zu verarbeiten, die in der View aufgrund der Notwendigkeit, Inhalte anzuzeigen, enthalten ist. Die WPF von Microsoft bringt neue technische Erfahrungen mit sich, wie z.B. Silverlight, Audio, Video, 3D, Animation..., was dazu geführt hat, dass die Software-UI-Schicht detaillierter und anpassbarer ist. Gleichzeitig bringt WPF auf technischer Ebene auch neue Funktionen wie Binding, Dependency Property, Routed Events, Command, DataTemplate, ControlTemplate usw. mit sich. Der Ursprung des MVVM-Frameworks (Model-View-ViewModel) ist ein neuer Architekturframework, der sich aus der Anwendungsmethode der Kombination des MVP-Musters (Model-View-Presenter) mit WPF entwickelt hat. Es basiert auf dem ursprünglichen MVP-Framework und enthält die neuen Funktionen von WPF, um mit den zunehmend komplexen Änderungen der Kundenbedürfnisse umzugehen.

Komponenten des MVVM-Musters

+-------------------+
| Model |
| Domänenmodell (objektorientiert) oder Datenzugriffsschicht |
| (datenzentriert), die den realen Zustandsinhalt darstellt |
+-------------------+
 |
 | Daten bereitstellen
 ▼
+-------------------+
| ViewModel |
| Die Abstraktion der View, die öffentliche Eigenschaften und Befehle verfügbar macht, |
| die zwischen der View und dem Data Binder kommuniziert |
+-------------------+
 |
 | Bidirektionale Bindung
 ▲
+-------------------+
| View |
| Die Struktur, das Layout und das Erscheinungsbild (UI), das der Benutzer auf dem Bildschirm sieht |
+-------------------+

1. Model: Das Modell bezieht sich auf das Domänenmodell (objektorientiert), das den realen Zustandsinhalt darstellt, oder auf die Datenzugriffsschicht (datenzentriert), die den Inhalt darstellt.
2. View: Genau wie in den MVC- und MVP-Mustern ist die View die Struktur, das Layout und das Erscheinungsbild (UI), das der Benutzer auf dem Bildschirm sieht.
3. ViewModel: Das View-Modell ist die Abstraktion der View, die öffentliche Eigenschaften und Befehle verfügbar macht. MVVM hat nicht den Controller im MVC-Muster, noch den Presenter im MVP-Muster, sondern hat einen Binder. Im View-Modell kommuniziert der Binder zwischen der View und dem Data Binder.
4. Binder: Deklarative Daten- und Befehlsbindung sind im MVVM-Muster implizit enthalten. Im Microsoft-Lösungsstack ist der Binder eine Auszeichnungssprache namens XAML. Der Binder befreit Entwickler davon, gezwungen zu sein, Boilerplate-Logik zu schreiben, um das View-Modell und die View zu synchronisieren. Wenn sie außerhalb des Microsoft-Stacks implementiert wird, ist das Aufkommen der deklarativen Datenbindungstechnologie ein Schlüsselfaktor für die Implementierung dieses Musters.

Vorteile von MVVM

Wie das MVC-Muster besteht der Hauptzweck des MVVM-Musters darin, die View und das Modell zu trennen, und es hat mehrere Hauptvorteile:

1. Geringe Kopplung: Die View kann sich unabhängig vom Modell ändern und modifiziert werden. Ein ViewModel kann an verschiedene "Views" gebunden werden. Wenn sich die View ändert, kann das Modell unverändert bleiben, und wenn sich das Modell ändert, kann auch die View unverändert bleiben.
2. Wiederverwendbarkeit: Sie können etwas View-Logik in ein ViewModel einfügen und viele Views diese View-Logik wiederverwenden lassen.
3. Unabhängige Entwicklung: Entwickler können sich auf die Entwicklung von Geschäftslogik und Daten (ViewModel) konzentrieren, und Designer können sich auf das Seitendesign konzentrieren. Mit Expression Blend ist es einfach, die Schnittstelle zu entwerfen und XAML-Code zu generieren.
4. Testbarkeit: Die Schnittstelle war schon immer relativ schwer zu testen, und jetzt können Tests für das ViewModel geschrieben werden.

Unterschiede zwischen MVVM und MVP

Das MVVM-Muster benennt den Presener in View Model um, was im Grunde genau dasselbe ist wie das MVP-Muster. Der einzige Unterschied besteht darin, dass es die bidirektionale Bindung (Data-Binding) verwendet: Änderungen in der View werden automatisch im View Model widergespiegelt und umgekehrt. Auf diese Weise müssen sich Entwickler nicht mit der Arbeit des Empfangens von Ereignissen und Aktualisierens der View befassen, und das Framework hat dies bereits für Sie erledigt.

Leapcell: Das Beste aus Serverlosem Webhosting

Schließlich empfehle ich eine Plattform, die sich am besten für die Bereitstellung von Webservices eignet: Leapcell

🚀 Mit Ihrer Lieblingssprache bauen

Mühelose Entwicklung in JavaScript, Python, Go oder Rust.

🌍 Unbegrenzte Projekte kostenlos bereitstellen

Zahlen Sie nur für das, was Sie nutzen – keine Anfragen, keine Gebühren.

⚡ Pay-as-You-Go, keine versteckten Kosten

Keine Leerlaufgebühren, nur nahtlose Skalierbarkeit.

📖 Entdecken Sie unsere Dokumentation

🔹 Folgen Sie uns auf Twitter: @LeapcellHQ