Réponse.

Contexte

Le modèle Model-View-Controller (MVC) est un modèle architectural classique, apparu bien avant Swift, et utilisé pour séparer les données, l'interface utilisateur et la logique de contrôle. Dans l'histoire du développement iOS, le MVC a été proclamé par Apple comme le modèle architectural principal pour construire des applications en Objective-C et Swift.

Problème

Le principal problème du MVC standard est qu'avec le temps, les contrôleurs deviennent des "Massive View Controllers", combinant la logique métier, l'interaction avec le modèle, le traitement des entrées utilisateur, et même la logique d'affichage. Cela entraîne une baisse de la lisibilité, de la réutilisabilité et de testabilité du code.

Solution

En Swift, le MVC est réalisé en utilisant des classes UIViewController pour le contrôleur, des modèles sous forme de structures ou de classes, et des UIView pour construire l'interface. Le contrôleur relie le modèle et la vue, en initiant la mise à jour de l'interface lors des modifications de données.

Exemple de code :

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

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

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

Caractéristiques clés :

Lien entre les couches via le contrôleur.
Le modèle ne connaît pas la vue.
La logique des entrées utilisateur et de navigation réside dans le contrôleur.

Questions pièges.

Peut-on avoir des dépendances entre la Vue et le Modèle directement dans le MVC ?

Non, la vue ne doit pas interagir directement avec le modèle. Toute communication se fait uniquement à travers le contrôleur ; sinon, le modèle "sait" sur la vue, ce qui viole le principe de séparation des responsabilités et complique l'évolutivité.

Le contrôleur peut-il contenir des données et de la logique métier ?

On pense souvent à tort que le contrôleur peut contenir la logique métier. En réalité, la logique métier doit être déplacée vers le modèle ou des services séparés, le contrôleur devant uniquement gérer le cycle de vie de la vue et la synchronisation des données.

Comment lutter contre les contrôleurs massifs (Massive View Controller) ?

Pour lutter contre les contrôleurs massifs, déplacez le traitement des données du contrôleur vers le modèle ou les services, utilisez des délégués, des modèles de délégation et de composition. Créez des classes séparées pour configurer la vue ou intégrez la logique d'affichage directement dans la vue.

Erreurs typiques et anti-modèles

Le modèle communique directement avec la vue
Contrôleur massif (Massive View Controller)
Stockage de l'état de la vue dans le contrôleur
Absence de mise en avant de la logique métier dans le modèle

Exemple de la vie réelle

Cas négatif

Dans un projet, le contrôleur stockait à la fois les données de l'utilisateur, leur traitement et le code d'affichage. La logique ne pouvait pas être réutilisée dans un autre contrôleur, et il était très difficile de tester la logique métier.

Avantages :

Démarrage rapide, peu de classes

Inconvénients :

Code peu lisible
Difficultés de maintenance et de test

Cas positif

Le modèle ne s'occupe que des données et de la logique métier, la vue dessine l'interface, le contrôleur les relie. Cela a permis une meilleure réutilisation des composants, des tests et un développement plus rapide de l'application.