MVC vs. MVP vs. MVVM: Gemeinsame Android-Architekturmuster erklärt

Während Sie als Entwickler arbeiten, müssen Sie von Architekturmustern gehört haben. In unserer Android-Welt sind die bekanntesten MVC , MVP und MVVM . Sie kennen wahrscheinlich ihre Eigenschaften, aber kennen Sie die Unterschiede und wann Sie sie verwenden?

Wenn Sie sich diese Fragen stellen, ist dieser Artikel für Sie.

MVC – Model-View-Controller

Model-View-Controller (MVC) ist ein Architekturmuster, das hilft, die Struktur unserer Anwendung zu organisieren. Es teilt seine Verantwortlichkeiten in drei Schichten auf: Model, View und Controller.

Brauchen Sie Android-Experten?

Arbeite mit uns!

• Modell – Datenschicht, verantwortlich für die Verwaltung der Geschäftslogik und die Unterstützung von Netzwerk- oder Datenbank-APIs. Das Modell arbeitet mit den entfernten und lokalen Datenquellen, um die Daten abzurufen und zu speichern. Hier wird die Geschäftslogik behandelt.
• Ansicht – UI-Schicht, verantwortlich für die Datenvisualisierung vom Modell zum Benutzer. Es verwaltet die Art und Weise, wie Daten präsentiert werden, einschließlich der grafischen Benutzeroberfläche.
• Controller – Eine logische Schicht, die die Ansichts- und Modellschichten integriert. Die Aufgabe des Controllers besteht darin, Benutzereingaben zu übernehmen und zu bestimmen, was damit zu tun ist.

Wie die einzelnen Komponenten kommunizieren, können Sie sehr schnell in der folgenden Grafik erkennen:

Wie es funktioniert?

Im Laufe der Jahre sind mehrere MVC-Varianten entstanden, aber ich werde hier die zwei beliebtesten erwähnen: Passives Modell und aktives Modell.

Passives Modell

In dieser Version von MVC ist der Controller die einzige Klasse, die das Modell manipuliert. Um diesen Vorgang gut zu veranschaulichen, verwende ich die folgende Grafik:

1. Der Controller reagiert auf die Aktionen des Benutzers und kontaktiert das Modell.
2. Wenn das Modell geändert wird, weist der Controller die Ansicht an, ihre Daten zu aktualisieren.
3. Die Ansicht ruft die aktualisierten Daten aus dem Modell ab und zeigt sie dem Benutzer an.

Aktives Modell

In dieser Version von MVC bearbeiten andere Klassen neben dem Controller das Modell.

In diesem Fall wird das Beobachtermuster verwendet, und die Ansicht wird als Modellbeobachter registriert. Dadurch wird die Ansicht ständig aktualisiert, wenn sich das Modell ändert.

Vorteile

1. Das MVC-Muster unterstützt das Trennungsproblem stark. Es erhöht die Testbarkeit des Codes und erleichtert seine Erweiterung, wodurch neue Funktionen einfach implementiert werden können.
2. Die Model-Klasse hat keinen Bezug zu den Android-Systemklassen, was den Komponententest sehr einfach macht.
3. Der Controller erweitert oder implementiert keine Android-Klassen. Es ermöglicht Unit-Tests.

Nachteile

1. Die Ansicht bezieht sich sowohl auf den Controller als auch auf das Modell.
   • Die Abhängigkeit der Ansicht vom Modell verursacht hauptsächlich Probleme in erweiterten Ansichten. Wieso den? Wenn die Rolle des Modells darin besteht, Rohdaten bereitzustellen, übernimmt die Ansicht die Handhabung der Benutzeroberflächenlogik.
     Wenn das Modell andererseits Daten anzeigt, die direkt für die Anzeige vorbereitet wurden, erhalten wir Modelle, die sowohl Geschäftslogik als auch UI-Logik unterstützen.
   • Die aktive Implementierung des Modells erhöht die Anzahl der Klassen und Methoden exponentiell, da Beobachter für jeden Datentyp benötigt werden sollten.
   • Wenn eine Ansicht sowohl vom Controller als auch vom Modell abhängt, können Änderungen an der UI-Logik Aktualisierungen/Änderungen an mehreren Klassen erfordern, wodurch die Flexibilität des Musters verringert wird.
2. Die Handhabung der UI-Logik ist nicht auf eine Klasse beschränkt. Für einen neuen Programmierer ist dies ein ziemliches Problem, und die Wahrscheinlichkeit für die Aufteilung der Verantwortlichkeiten zwischen Model, View und Controller ist sehr hoch.
3. Im Laufe der Zeit, insbesondere bei Anwendungen mit anämischen Modellen, wird immer mehr Code an die Controller gesendet , wodurch sie aufgebläht und spröde werden.

Zusammenfassung

Die Abhängigkeit von View vom Model und das Vorhandensein von Logik in View kann die Qualität des Codes in unserer Anwendung erheblich verschlechtern. Wir können diese Gefahr verringern, indem wir andere Muster wählen, insbesondere solche, die für mobile Anwendungen vorgeschlagen werden. Lesen Sie weiter unten darüber.

MVP – Model-View-Moderator

Model-View-Presenter (MVP) ist ein Architekturmuster, mit dem wir die Schwächen des MVC-Musters umgehen können. Es bietet Modularität, Testbarkeit und eine viel klarere und einfacher zu wartende Codebasis.

MVP unterteilt die Anwendungsstruktur in die Ebenen View , Model und Presenter :

• Modell – Analog zum MVC-Muster.
• Ansicht – UI-Schicht, verantwortlich für die Darstellung der Daten für den Benutzer in der vom Präsentator festgelegten Weise. Sie kann durch Aktivitäten, Fragmente oder eine beliebige allgemeine Ansicht implementiert werden.
• Presenter – Die Logikschicht, die zwischen der Ansichts- und der Modellschicht vermittelt. Es kontaktiert sowohl die Ansichts- als auch die Modellebene und reagiert auf Aktionen des Benutzers.

Wie es funktioniert?

In MVP sind View und Presenter völlig getrennt und kommunizieren durch Abstraktionen miteinander. Die Contract-Schnittstellenklassen definieren die Beziehung zwischen ihnen. Dank ihnen ist der Code besser lesbar und die Verbindung zwischen den Schichten ist leicht zu verstehen. Wenn Sie an den Implementierungsdetails interessiert sind, lesen Sie bitte Model-View-Presenter: Android-Richtlinien.

Es ist erwähnenswert, dass der Presenter keine Verweise auf eine Android-spezifische API haben darf.

Sehen Sie sich das Bild unten an, um einen guten Überblick über den Datenaustauschprozess zwischen den einzelnen Komponenten zu erhalten. Für die Zwecke dieses Artikels wird dieses Beispiel vereinfacht:

1. Der Benutzer führt die Aktion aus.
2. Der Presenter reagiert auf die Aktion des Benutzers und sendet eine entsprechende Anfrage an das Model.
3. Das Modell wird aktualisiert und neue Daten werden an den Presenter gesendet.
4. Der Presenter bereitet die Daten für die Anzeige vor und sendet sie an View.
5. Die Ansicht zeigt dem Benutzer die Daten an.

Vorteile

1. Wir können die Presenter-Logik einfach testen, da sie nicht an Android-spezifische Ansichten und APIs gebunden ist.
2. Die Ansicht und der Presenter sind vollständig getrennt , was das Verspotten einer Ansicht vereinfacht und das Testen von Einheiten oberflächlicher macht als damals in der MVC
3. Wir haben nur eine Klasse , die alles im Zusammenhang mit der Präsentation einer Ansicht behandelt – den Presenter.

Nachteile

1. Der Präsentator neigt wie der Controller dazu, zusätzliche Geschäftslogik anzusammeln. Um dieses Problem zu lösen, zerlegen Sie Ihren Code und denken Sie daran, Klassen mit nur einer Verantwortung zu erstellen.
2. Während dies ein großartiges Muster für eine Android-App ist, kann es sich bei der Entwicklung einer kleinen App oder eines Prototyps überwältigend anfühlen.

Zusammenfassung

Im Vergleich zu MVC ist dieses Muster viel besser. Es löst zwei kritische Probleme des MVC-Musters:

1. Die Ansicht bezieht sich nicht mehr sowohl auf den Controller als auch auf das Modell.
2. Es gibt nur eine Klasse, die alles behandelt, was mit der Präsentation der Ansicht zu tun hat: den Presenter.

MVVM – Model-View-ViewModel

Model-View-ViewModel (MVVM) ist ein ereignisbasiertes Muster. Dadurch können wir schnell auf Konstruktionsänderungen reagieren. Dieses Architekturmuster ermöglicht es uns, die Benutzeroberfläche noch stärker von der Geschäfts- und Verhaltenslogik zu trennen als im Fall von MVC oder MVP.

• ViewModel – Befasst sich mit der Übermittlung von Daten aus dem Modell an die Ansichtsschicht und der Handhabung von Benutzeraktionen. Erwähnenswert ist, dass es die Datenströme für View bereitstellt.
• Ansicht – Die UI-Schicht ist verantwortlich für die Darstellung von Daten, Systemstatus und aktuellen Vorgängen in der grafischen Oberfläche. Abgesehen davon initialisiert und bindet es ViewModel mit View-Elementen (informiert ViewModel über Benutzeraktionen).
• Modell – Wie MVC – keine Änderung.

Wie es funktioniert?

Die Idee des MVVM -Patterns basiert hauptsächlich darauf, dass die View -Schicht (Observer-Pattern) die sich ändernden Daten in der ViewModel -Schicht beobachtet und über den Datenbindungsmechanismus auf Änderungen reagiert.

Die Implementierung des MVVM-Musters kann auf viele Arten erreicht werden. Es lohnt sich jedoch, den Datenbindungsmechanismus darin einzubeziehen. Dadurch wird die Logik des View-Layers minimiert, der Code übersichtlicher und das Testen einfacher.

Wenn das MVP-Muster bedeutet, dass der Präsentator der Ansicht direkt mitteilt, was angezeigt werden soll, stellt das MVVM-ViewModel die Ereignisströme bereit, denen die Ansichten zugeordnet werden können. Das ViewModel muss keinen Verweis mehr auf die Ansicht speichern, wie es beim Presenter der Fall war. Es bedeutet auch, dass alle Schnittstellen, die das MVP-Muster erfordert, jetzt unnötig sind.

Ansichten benachrichtigen das ViewModel auch über verschiedene Aktionen, wie in der obigen Grafik zu sehen ist. Daher unterstützt das MVVM-Muster die bidirektionale Datenbindung zwischen View und ViewModel. Die View hat einen Verweis auf ViewModel, aber ViewModel hat keine Informationen über View.

Vorteile

1. Komponententests sind einfacher , da Sie nicht von der Ansicht abhängig sind. Es reicht aus, zu überprüfen, ob die beobachtbaren Variablen richtig positioniert sind, wenn sich das Modell beim Testen ändert.
2. ViewModels sind sogar noch benutzerfreundlicher für Komponententests, da sie lediglich den Zustand offenlegen und daher unabhängig getestet werden können, ohne zu testen, wie die Daten verbraucht werden. Kurz gesagt, es gibt keine Abhängigkeit von der Ansicht.
3. Nur der View enthält einen Verweis auf das ViewModel, nicht umgekehrt. Dies löst das Problem der engen Kopplung. Eine einzelne Ansicht kann auf mehrere ViewModels verweisen.
4. Selbst für komplexe Ansichten können wir verschiedene ViewModels in derselben Hierarchie haben.

Nachteile

1. Die Verwaltung von ViewModels und ihrem Status in komplexen Benutzeroberflächen ist für Anfänger manchmal eine Herausforderung.

Zusammenfassung

MVVM kombiniert die Vorteile von MVP und nutzt die Vorteile von Datenbindung und ereignisbasierter Kommunikation. Das Ergebnis ist ein Muster, in dem das Modell so viele Operationen wie möglich steuert, mit hoher Codetrennung und Testbarkeit.

MVC vs. MVP vs. MVVM: Vergleich

MVC vs. MVP vs. MVVM: Zusammenfassung

Sowohl das MVP- als auch das MVVM-Muster schneiden deutlich besser ab als das MVC-Muster. Welchen Weg Sie wählen, hängt wirklich von Ihren Vorlieben ab. Ich hoffe jedoch, dass dieser Artikel Ihnen die wichtigsten Unterschiede zwischen ihnen aufgezeigt hat und Ihnen die Wahl erleichtert.

Suchen Sie nach einer Alternative?

Wählen Sie plattformübergreifend!

Literaturverzeichnis:

1. Cervone, S. (2017) Model-View-Presenter: Android-Richtlinien.
2. Dang, AT (2020) MVC vs. MVP vs. MVVM.
3. Muntenescu, F. (2016) Android-Architekturmuster Teil 1: Model-View-Controller.
4. Muntenescu, F. (2016) Android Architecture Patterns Part 2: Model-View-Presenter.
5. Muntenescu, F. (2016) Android-Architekturmuster Teil 3: Model-View-ViewModel.