MVP vs. MVC vs. MVVM vs. VIPER. Was ist besser für die iOS-Entwicklung?

So wie jedes Haus einen soliden Keller hat, hat jedes Softwareprojekt eine Softwarearchitektur, auf der es aufbaut, und jedes Projekt hat seine eigene App-Struktur. Die Arten von Architekturmustern können variieren, aber es gibt 4 am häufigsten verwendete - diejenigen, die die gesamte IT-Welt ständig kritisiert, aber gleichzeitig verwendet: MVC, MVP, MVVM und Viper (das letzte meist als iOS-Architekturmuster) . Der Vergleich dieser Muster und die Auswahl einer besseren Passform für den Fall jedes von Swift geschriebenen Projekts werden weiter unten in diesem Artikel beschrieben.

Der chronologischen Reihenfolge der Dinge folgend, dauerte es nicht lange, bis die gemeinsamen Probleme dieser ios-Entwicklungsarchitekturmuster nach dem Erscheinen der ersten Software-Entwurfsmuster auftraten.

Zum Beispiel das Problem der Server-Client-Kommunikation – wie interagiert einer mit einem anderen? Oder ein anderes - das Problem, die Geschäftslogik der Anwendung von der Logik der App zu trennen; Wie sollte dieser in Bezug auf die Architektur der Anwendung funktionieren? Durch sie haben verschiedene Entwurfsmuster für unterschiedliche Architekturschichten die Welt gesehen; die bekanntesten unter ihnen sind:

- Singleton-Designmuster.

Dieses Muster ermöglicht es, eine Klasse nur auf ein Objekt anzuwenden, und diese Option ist nützlich, wenn eine begrenzte Anzahl von Instanzen (oder nur eine Instanz) vom System genehmigt wird.

- Dekorateur-Designmuster.

Im Gegensatz zu Singleton ermöglicht dieses Muster (alternativ auch Wrapper zusammen mit dem Adapter-Muster genannt) einem einzelnen Objekt ein bestimmtes Verhalten hinzuzufügen (entweder statisch oder dynamisch), und dies alles ohne das Verhalten anderer Objekte zu beeinflussen man teilt sich eine Klasse mit.

- Brückenentwurfsmuster.

Dieses Architekturmuster, das erstmals von der berüchtigten Gang of Four – den Autoren des Buches „Design Patterns“ eingeführt wurde, „verwendet Kapselung, Aggregation und kann Vererbung verwenden, um Verantwortlichkeiten in verschiedene Klassen aufzuteilen Programmierung sehr nützlich, da Änderungen am Code eines Programms leicht mit minimalen Vorkenntnissen des Programms vorgenommen werden können. [Quelle: Wiki]

Obwohl diese Muster ziemlich unterschiedlich sind, sind bei jedem von ihnen die üblichen Probleme von Code-Autoren aufgetreten; zum Beispiel mit Singletons „Massivität“. Singleton ist zu global, da die Abhängigkeiten Ihres Codes tief in Ihrer Anwendung verborgen sind, anstatt in den Schnittstellen offengelegt zu werden. Deshalb tauchen während des Softwareentwicklungsprozesses ständig neue Muster auf.

Die 4 am häufigsten verwendeten Muster sind MVC, MVP, MVVM und VIPER (hauptsächlich für iOS).

Sie wurden in der gleichen Reihenfolge wie aufgelistet entwickelt und haben alle ihre eigenen Vorteile und Schwächen, was zu zahlreichen Streitigkeiten darüber führt, wo sie jeweils angewendet werden sollen. Wenn man den Best Practices, die sie implementieren, etwas mehr Aufmerksamkeit schenkt, könnte dies ein wenig Klarheit schaffen.

MVC-Muster

Der Urvater aller Softwaremuster, die Anfang der 1970er Jahre von dem norwegischen Informatiker Trygve Reenskaug eingeführt wurden, Module - View - Controller, weithin bekannt als MVC, ist einer der ersten Musteransätze der objektorientierten Programmierung.

Der Ansichtsteil ist dafür verantwortlich, alles für den Systembenutzer anzuzeigen (Oberflächen von Mobil- oder Web-App usw.). Model ist im Allgemeinen für die Datenbanken, Geschäftseinheiten und den Rest der Daten verantwortlich. Der Controller wiederum regelt die Arbeit des Modells, die Bereitstellung von Daten an die Datenbank, die Anzeige von der genannten Datenbank an den View-Teil und umgekehrt.

So universell das MVC-Modell auch sein mag, die beiden größten Konkurrenten - Apple und Google - haben ihre eigenen Muster, die das Modell - Ansicht - Controller-System darstellen. Das Problem des Apple-Systems liegt in der engen Verbindung zwischen View- und Controller-Teilen, die fast so eng sind, dass sie View & Controller vereint haben und Model-Teile getrennt bleiben.

Folglich führt dies zu einem schlechten Testprozess - nur das Modell konnte untersucht werden, V&C (aufgrund der engen Verbindung) können überhaupt nicht getestet werden.

Die robuste Verbindung zwischen Controller- und View-Segmenten erwies sich in Bezug auf Software als wirklich „ungesund“, so dass bald ein neues Muster die Welt erblickte.

MVP-Muster.

Viele von uns haben diese Abkürzung im Zusammenhang mit Minimum Viable Product gehört, aber in Bezug auf Software-Engineering bedeutet sie etwas anderes. Das Model View Presenter-Muster weist wenige Schlüsselpunkte auf, die eine große Kluft zwischen ihm und MVC bilden:

MVP-Modell

• Die Ansicht ist lockerer an das Modell gekoppelt. Der Präsentator ist dafür verantwortlich, das Modell an die Ansicht zu binden.

• Einfachere Komponententests, da die Interaktion mit der Ansicht über eine Schnittstelle erfolgt.

• Normalerweise View to Presenter = Karte eins zu eins. Komplexe Ansichten können mehrere Moderatoren haben.

MVC-Muster

• Controller basieren auf Verhaltensweisen und können ansichtsübergreifend geteilt werden

• Kann dafür verantwortlich sein, zu bestimmen, welche Ansicht angezeigt werden soll
  [Quelle: Infragistics]

In dieser Anordnung bleiben die Funktionen von Model gleich; Presenter ist jeweils für die Geschäftslogik verantwortlich. Der V-Teil ist von besonderem Interesse, da er in zwei Teile View und View Controller unterteilt ist, die für die Interaktion zuständig sind. Wenn es eine MVVM vs. MVC-Frage gibt, löst das System dieses Typs das Problem einer „schweren Sucht“-Ansicht und Controller-Modi, die im MVC-Muster verwendet werden.

Auch hier ist das Testhindernis gelöst, da Model-, View mit Benutzerinteraktion und Presenter-Teile alle getestet werden konnten.
Die noch bestehenden Unannehmlichkeiten sind von Presenter zu verdanken - aber viel zu massiv, berücksichtigen aber alle bestehenden Geschäftslogiken. Deshalb kam der nächste Akt ins Spiel, genannt…

MVVM-Muster

Ein Model-View-ViewModel- Softwarearchitekturmuster wurde 2005 von John Gossman, einem der Architekten von Microsoft, erstellt. Die drei Kernkomponenten des MVVM-Modells sind jeweils:
Modell ist „eine Implementierung des Domänenmodells der Anwendung, die ein Datenmodell zusammen mit Geschäfts- und Validierungslogik enthält. Beispiele für Modellobjekte sind Repositorys, Geschäftsobjekte, Datenübertragungsobjekte (DTOs), Plain Old CLR Objects (POCOs) und generierte Entitäts- und Proxy-Objekte.“ [Quelle: Microsoft]

View ist wieder alles, was der Benutzer sehen kann - das Layout, die Struktur und das Aussehen von allem auf dem Bildschirm. Im Grunde wäre es innerhalb der Anwendung die Seite der App. View ruft und sendet Aktualisierungen nur an ViewModel, ausgenommen die gesamte Kommunikation zwischen diesem Teil und dem Model selbst.

ViewModel soll eine „Verbindungskette“ zwischen den View- und Model-Systemkomponenten sein, und seine Hauptfunktion besteht darin, die Logik der View zu handhaben. Normalerweise interagiert das Ansichtsmodell mit dem Modell, indem es Methoden in den Modellklassen aufruft. Das Ansichtsmodell stellt dann Daten aus dem Modell in einer Form bereit, die die Ansicht problemlos verwenden kann, wie Microsoft angibt.

Der Hauptunterschied zwischen MVC und iOS MVVM besteht darin, dass das Verteilungsmuster von MVVM besser ist als bei dem zuvor aufgeführten MVC, aber im Vergleich zu MVP auch massiv überlastet. Das Testen ist hier von besonderer Bedeutung, da Sie beim einfachen Schreiben des Codes nicht garantieren können, dass das gesamte Projekt richtig funktioniert - Tests helfen, dies zu gewährleisten.

Die Evolution des nächsten Architekturmusters wurde vor kurzem veröffentlicht und ist jetzt der aktuellste Softwarearchitekturansatz.

iOS VIPER-Architektur

Auf der Suche nach der besten Architekturlösung stießen iOS-Entwickler auf der ganzen Welt auf einen sogenannten „Clean Architecture“-Ansatz, der von Onkel Bob auf den Clean Coders eingeführt wurde – einer bekannten Plattform, die Schulungen für Software-Profis weltweit anbietet.

Clean Architecture teilt die logische Struktur der Anwendung in mehrere Verantwortungsebenen auf. Diese „Trennung“ wiederum löst die engen Abhängigkeitsprobleme und erhöht die Testverfügbarkeit auf allen Ebenen.

VIPER für die iOS-Entwicklung

VIPER ist eine Realisierung von Clean Architecture für iOS-basierte Anwendungen. Als allgemeine Regel für alle Musternamen ist es auch ein Backronym für View, Interactor, Presenter, Entity und Routing. Jeder Teil des VIPER ist für ein bestimmtes Element verantwortlich, insbesondere:

1. View ist dafür verantwortlich, die Aktionen des Benutzers mit einer Schnittstelle zu spiegeln

2. Die Verantwortlichkeiten des Präsentators innerhalb des VIPER-Musters sind ziemlich begrenzt - er empfängt die Aktualisierungen von Entity, sendet jedoch keine Daten an ihn;

3. Interactor ist der Teil des Systems, der tatsächlich Entitäten entspricht. Dieses Schema funktioniert in die folgende Richtung: Presenter informiert Interactor über die Änderungen im View-Modell, dann kontaktiert Interactor den Entity-Teil und kehrt mit den von Entity erhaltenen Interactor-Daten zu Presenter zurück, der View befiehlt, sie für einen Benutzer zu spiegeln. Alle Datenmodelle, alle Entitäten und alle Websites sind mit dem Interactor-Teil verbunden.

4. Entity besteht aus Objekten, die von Interactor gesteuert werden (Titel, Inhalt usw.). Es interagiert nie direkt mit Presenter, sondern nur über den I-Anteil.

5. Routing (oder Wireframe, wie es manchmal genannt wird) ist für die Navigation zwischen allen Bildschirmen und im Wesentlichen für das Routing verantwortlich. Wireframe steuert die Objekte von UIWindow, UINavigationController usw.

Insbesondere innerhalb des iOS-Architektursystems basiert alles auf einem Framework namens UIkit, das alle Komponenten von Apple MVC enthält, jedoch ohne eine enge Verbindung, die früher Programmierer in den Wahnsinn getrieben hat.

Das VIPER-Modul ist auch bei Unit-Tests von Vorteil, da Sie mit der Verteilung des großartigen Musters alle verfügbaren Funktionen testen können. In vielerlei Hinsicht war dies die Hauptschwierigkeit, mit der Entwickler mit früheren MVC-, MVP- und MVVM-Softwaremustern konfrontiert waren.

Um alles zu krönen.

Alle diese 4 Software-Design-Patterns werden oft als eines der besten Architektur-Patterns für die iOS-Entwicklung bezeichnet, obwohl sie alle nicht ideal sind und definitiv nicht für jedes einzelne Projekt verwendet werden, das Sie entwickeln. Auf der düsteren Seite ist hier eine kurze Liste der Probleme, die jedes Muster hat:

• MVC, MVP, MVVM – alle haben dieses Problem der „engen Verbindung“, was die Einführung von Updates in die Entwicklung und das anschließende Testen zu einer ziemlich harten Aufgabe macht.

• VIPER vs MVVM, MVC oder MVP gilt als ein Gewinnfall; obwohl es trotz seiner hohen Flexibilität und guten Testbarkeit auch viele Nuancen hat, die schwer zu generieren sind.

Gibt es eine 100 % feste Lösung? Nicht wirklich, aber für jedes Ihrer Projekte könnte eines dieser 4 iOS-App-Muster genau das sein, was Sie brauchen. Und wenn nicht, dann wäre eine Mischung aus zwei. Oder vielleicht sogar drei. Das Glück soll die Mutigen begünstigen, also warum spielen Sie nicht mutig mit Software-Designmustern?

Geschrieben von Max Mashkov und Elina Bessarabova.