MVC ohne C: Was ändert SwiftUI in der Anwendungsarchitektur?

MVC ist ein langjähriger Standard für Entwurfsmuster, die zum Schreiben von iOS-Anwendungen verwendet werden. Die Struktur von iOS-Anwendungen, die zuvor erstellt wurden, basierte auf einer Basiskomponente, die überall vorhanden ist und als Controller bezeichnet wird . SwiftUI , das keine solche Komponente hat, wurde auf der WWDC19 vorgestellt .

Das Problem mit den sogenannten massiven View-Controllern sollte in SwiftUI gelöst werden. Sie müssen also einen neuen Weg finden, um den Code korrekt zu zerlegen. Schauen wir uns den aktuellen Status der Plattform an und überlegen, welche Paradigmen wir bei der Entwicklung für iOS13 und höher verwenden können.

Unidirektionale und bidirektionale Architekturen

Die meisten Architekturlösungen, die große Unternehmen verwenden, sind bidirektional. Dies bedeutet, dass Sie sie als Schichten übereinander betrachten können und sie miteinander kommunizieren können, indem sie Daten sowohl nach oben als auch nach unten übertragen. Muster wie MVC, Model-View-ViewModel und sogar viele Implementierungen des MVVM-Musters mit Koordinatoren sind ebenfalls bidirektionale Architekturen.

Ein Beispiel für den derzeit weit verbreiteten unidirektionalen Datenstrom auf der iOS-Plattform ist die VIP-Schleife (Presentation-Interactive-Presenter) in den Clean Swift- oder Viper-Architekturen. Diese Architekturen sind nicht rein unidirektional. Router und ausführbare Dateien kommunizieren mit der VIP-Schleife in beide Richtungen.

Eine andere Sache, die wir beobachten können, ist, dass das MVC-Muster und andere Muster, die auf seiner Basis erstellt werden, mehr auf einem Bildschirm basieren und sich befinden. Normalerweise gibt es keine klare Struktur für Schreibdienste, Module usw., die mit verschiedenen Teilen der Anwendung interagieren.

Datenfluss in SwiftUI

Gemäß der WWDC-Präsentation war das Element, das Ansicht und Modell / Status in SwiftUI verbindet, eine bestimmte Store-Klasse, die dem BindableObject- Protokoll entspricht. Wir können nur hoffen, dass wir keine Anwendungen mit einem riesigen Speicher haben, der die gesamte Logik der Anwendung mit allen Zuständen ohne klare Struktur enthält. Ich glaube, dass die iOS-Community ziemlich weit fortgeschritten ist und in dieser Richtung besser abschneiden kann.

Wenn wir MVC und SwiftUI mit Ansicht und Speicher nebeneinander platzieren, sehen wir fast dieselbe Vorlage, was zu ähnlichen Problemen führen kann, die wir mit dem Ansichts-Controller hatten, jedoch ohne Standardcode wie VC hat in der Natur.


Wenn Sie MVC einfügen und in einem Diagramm speichern, sehen sie möglicherweise so aus.

Auf den ersten Blick scheint Combine das in SwiftUI verwendete Architekturmuster zu sein. Kombinieren ist jedoch nur ein Werkzeug zum Verarbeiten von Werten im Laufe der Zeit. In ähnlicher Weise ist MVVM, das RxSwift verwendet, immer noch MVVM, nur eine Verbindung zwischen Schichten, die auf verschiedene Arten implementiert wird.

Deklarative Architektur für deklarative Benutzeroberflächen

SwiftUI kann in wenigen Worten zusammengefasst werden, z. B. eine deklarative Benutzeroberfläche . Ich glaube, dass mehr erreicht werden kann, wenn Sie über den Tellerrand hinaus denken und sich auf das Wort „ deklarativ “ konzentrieren. Die fortschrittlichsten deklarativen Architekturbeispiele finden Sie in der Front-End-Anwendungsentwicklung. Konzepte wie ELM, Redux und Flux können problemlos mit der SwiftUI- und Combine-Infrastruktur verwendet werden. Swift hatte bereits mehrere Neuimplementierungen wie ReSwift , aber es wäre immer noch notwendig, diese Implementierungen in Combine zu kombinieren.


Leicht modifizierter Datenfluss in SwiftUI von WWDC19

Ich möchte von Anfang an ohne Abhängigkeiten mit SwiftUI spielen und experimentiere derzeit in Swift mit einer einfachen Implementierung der ELM-Architektur. Diese Architektur passt besser zu den Diagrammen, die Apple auf der WWDC gezeigt hat.

Wir können die Anwendung anhand dieser Architekturmuster beschreiben:

• Aktion ist ein Typ, der alle Ereignisse beschreibt, die in einer Anwendung auftreten können. (In einer einfachen Anwendung kann dies eine Aufzählung mit einem zugehörigen Wert sein. In einer großen Anwendung können Sie viele Strukturen verwenden, die dem Aktionsprotokoll entsprechen.)
• Update (oder Reduzierung in Redux) ist eine einfache Bereinigungsfunktion, die den aktuellen Status und die übermittelte Aktion übernimmt und den neuen geänderten Status zurückgibt. (Diese Funktionen verursachen keine Nebenwirkungen und können einfach kombiniert werden.)
• Status ist ein Typ, der den Status einer Anwendung beschreibt. (Eine einfache Liste von Aufgaben kann ein Array verwenden.)

Alle drei Elemente sind deklarativ und jedes von ihnen ist ein kleiner testbarer und wiederverwendbarer Teil des Puzzles, der zusammen die gesamte Anwendung ausmacht. Der Status wird im Store gespeichert und daraus kann eine Ansicht berechnet werden.


Status, Aktionen und Update für eine einfache Swift-Anwendung.

Für asynchrone Operationen könnten wir so etwas wie ein Middleware-Objekt in Redux oder Befehle in ELM einführen.

Fazit

Wir können entweder alle uns bekannten Architekturen verwenden, und wenn wir bestehende Anwendungen schrittweise um SwiftUI erweitern, ist dies ein zuverlässiger und sicherer Ansatz. Wenn eine neue Anwendung nur mit SwiftUI implementiert wird, können Sie einen offeneren Ansatz verwenden und etwas anderes ausprobieren.

Wenn Sie in naher Zukunft über die Entwicklung einer Anwendung mit SwiftUI nachdenken, würde ich empfehlen, einige Punkte zu beachten:

• Apple bietet keine detaillierten Anleitungen zur Anwendungsarchitektur. Dies bedeutet, dass wir als Community von Programmierern viele Möglichkeiten für Innovationen und die Implementierung neuer Ansätze haben.
• Wir werden definitiv einen viel größeren Maßstab verschiedener Codebasen sehen, da das Loch, das nach dem View Controller übrig bleibt, gefüllt werden muss.
• Halten Sie sich offen und haben Sie keine Angst, von vorne zu beginnen.

Meine Experimente finden Sie auf dem Spielplatz Swift (zum Vergleich wird die Implementierung und Verwendung von UIKit und SwiftUI, derselben Anwendung, vorgestellt).

Nächste Schritte

Es gibt viele Möglichkeiten, die wir nutzen können, aber ich bin stark geneigt, endlich einen viel funktionaleren Ansatz für die Anwendungsentwicklung auszuprobieren. Sie können also einige interessante Lösungen aus der Community sehen, und wir haben noch viel Zeit, um SwiftUI in unserer täglichen Arbeit zu verwenden. Es bleibt also noch Zeit zum Experimentieren und es besteht kein Druck auf uns.

Ich habe vor, mehr über diese Implementierung einer unidirektionalen und funktionalen Architektur zu schreiben. Ich hoffe, dass ich dies bald in einem kleinen realen Projekt verwenden kann, damit ich Ihnen mehr darüber erzählen kann, wie dieser Ansatz praktikabel ist und Leistungsprobleme in großen Projekten aufweist.