Antwort.

Geschichtlicher Hintergrund

Das Model-View-Controller (MVC)-Muster ist ein klassisches Architekturkonzept, das lange vor Swift entstanden ist und zur Trennung von Daten, Benutzeroberfläche und Steuerlogik verwendet wird. In der Geschichte der iOS-Entwicklung wurde MVC von Apple als das grundlegende Architekturkonzept für die Entwicklung von Anwendungen in Objective-C und Swift proklamiert.

Problem

Das Hauptproblem des Standard-MVC besteht darin, dass Controller im Laufe der Zeit zu "Massive View Controllers" werden, die Geschäftslogik, Kommunikation mit dem Modell, Verarbeitung von Benutzereingaben und sogar Anzeige-Logik vereinen. Dies führt zu einer geringeren Lesbarkeit, Wiederverwendbarkeit und Testbarkeit des Codes.

Lösung

In Swift wird MVC mit UIViewController-Klassen für den Controller, Modellen als Strukturen oder Klassen sowie UIView für den Aufbau der Benutzeroberfläche implementiert. Der Controller verbindet das Modell und die Ansicht und initiiert die Aktualisierung der Benutzeroberfläche bei Änderungen der Daten.

Codebeispiel:

struct User {
    let name: String
    let age: Int
}

class UserView: UIView {
    let nameLabel = UILabel()
    func display(user: User) {
        nameLabel.text = "\(user.name), \(user.age) Jahre"
    }
}

class UserController: UIViewController {
    var user: User?
    var userView: UserView!

    override func loadView() {
        userView = UserView()
        view = userView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        if let user = user {
            userView.display(user: user)
        }
    }
}

Wesentliche Merkmale:

Verbindung zwischen Schichten über den Controller.
Modell weiß nichts über die Ansicht.
Logik der Benutzereingabe und der Navigation im Controller.

Hinterfragte Fragen.

Sollten Abhängigkeiten zwischen der Ansicht und dem Modell direkt im MVC erlaubt sein?

Nein, die Ansicht darf nicht direkt mit dem Modell interagieren. Die gesamte Kommunikation erfolgt nur über den Controller; andernfalls "erfährt" das Modell von der Ansicht, was das Prinzip der Trennung der Verantwortlichkeiten verletzt und die Skalierbarkeit behindert.

Kann der Controller Daten und Geschäftslogik enthalten?

Es wird oft fälschlicherweise angenommen, dass der Controller Geschäftslogik enthalten kann. Tatsächlich sollte die Geschäftslogik in das Modell oder separate Dienste ausgelagert werden, und der Controller sollte nur den Lebenszyklus der Ansicht und die Datenabstimmung verwalten.

Wie bekämpft man massive Controller (Massive View Controller)?

Um massive Controller zu bekämpfen, sollte die Datenverarbeitung aus dem Controller in das Modell oder Dienste ausgelagert werden, verwenden Sie Delegaten, Delegationsmuster und Kompositionen. Erstellen Sie separate Klassen für die Konfiguration von Ansichten oder fügen Sie die Anzeige-Logik direkt in die Ansicht ein.

Typische Fehler und Anti-Pattern

Modell kommuniziert direkt mit der Ansicht
Massiver Controller (Massive View Controller)
Speicherung des Zustands der Ansicht im Controller
Fehlen der Trennung der Geschäftslogik in das Modell

Beispiel aus dem Leben

Negativer Fall

Im Projekt speicherte der Controller sowohl die Benutzerdaten als auch deren Verarbeitung und den Anzeige-Code. Es war unmöglich, die Logik in einem anderen Controller wiederzuverwenden, und es war sehr schwierig, die Geschäftslogik zu testen.

Vorteile:

Schneller Start, wenige Klassen

Nachteile:

Schwer lesbarer Code
Schwierigkeiten bei Wartung und Testung

Positiver Fall

Das Modell ist nur für Daten und Geschäftslogik verantwortlich, die Ansicht zeichnet die Benutzeroberfläche, und der Controller verbindet beides. Dadurch entstanden Möglichkeiten zur Wiederverwendbarkeit von Komponenten, einfacheren Tests und schnelleren Skalierungen der Anwendung.