Antwoord.

Geschiedenis van de vraag

Het Model-View-Controller (MVC) patroon is een klassiek architectonisch patroon dat lang vóór Swift is ontstaan en wordt gebruikt voor het scheiden van gegevens, gebruikersinterface en besturingslogica. In de geschiedenis van iOS-ontwikkeling werd MVC door Apple uitgeroepen tot het belangrijkste architectonische patroon voor het bouwen van applicaties in Objective-C en Swift.

Probleem

Het belangrijkste probleem van de standaard MVC is dat controllers in de loop der tijd "Massive View Controllers" worden, waarin zakelijke logica, interactie met het model, verwerking van gebruikersinvoer en zelfs weergavelogica worden samengevoegd. Dit leidt tot verminderde leesbaarheid, herbruikbaarheid en testbaarheid van de code.

Oplossing

In Swift wordt MVC geïmplementeerd met behulp van UIViewController klassen voor de controller, modellen als structuren of klassen en UIView voor het bouwen van de interface. De controller verbindt model en weergave en initieert een interface-update bij gegevenswijzigingen.

Voorbeeldcode:

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

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

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)
        }
    }
}

Belangrijkste kenmerken:

Verbinding tussen lagen via de controller.
Model kent de view niet.
Logica van gebruikersinvoer en navigatie in de controller.

Vragen met een valstrik.

Mag er een directe afhankelijkheid zijn tussen View en Model in MVC?

Nee, de View mag niet rechtstreeks communiceren met de Model. Alle communicatie vindt alleen plaats via de Controller; anders "weet" het model van de weergave, wat het principe van verantwoordelijkheidsverdeling schendt en de schaalbaarheid bemoeilijkt.

Kan de Controller gegevens en zakelijke logica bevatten?

Het wordt vaak ten onrechte gedacht dat de controller zakelijke logica kan bevatten. In feite moet zakelijke logica in de Model of afzonderlijke services worden geplaatst, en de controller moet alleen het levenscyclusbeheer van de View en de gegevenscoördinatie verzorgen.

Hoe om te gaan met massieve controllers (Massive View Controller)?

Om massieve controllers te bestrijden, verplaatst u gegevensverwerking van de controller naar de Model of services, gebruikt u delegates, delegatiepatronen en compositie. Maak aparte klassen voor het instellen van de View of breng weergavelogica rechtstreeks in de View onder.

Typische fouten en anti-patronen

De model communiceert rechtstreeks met de View
Massieve controller (Massive View Controller)
Staat van de View bewaren in de controller
Het ontbreken van zakelijke logica in de Model

Voorbeeld uit het leven

Negatieve casus

In een project bewaarde de controller zowel gebruikersgegevens als de verwerking daarvan en de weergavecode. Het was onmogelijk om de logica in een andere controller herbruikbaar te maken en het was zeer moeilijk om de zakelijke logica te testen.

Voordelen:

Snelle start, weinig klassen

Nadelen:

Slecht leesbare code
Moeilijkheden met onderhoud en testen

Positieve casus

De Model is alleen verantwoordelijk voor gegevens en zakelijke logica, de View tekent de interface, de Controller verbindt hen. Er ontstond een mogelijkheid om componenten opnieuw te gebruiken, het te testen en de applicatie sneller te schalen.