Modèles architecturaux en Swift : MVC, MVVM et VIPER avec exemples

Modèles architecturaux en Swift : du chaos à l'ordre

Chaque développeur iOS est tôt ou tard confronté à la question : "Comment organiser le code pour que le projet ne se transforme pas en spaghettis dans six mois ?" La réponse est simple : les modèles architecturaux. En Swift, comme dans tout autre langage, le choix de l'architecture détermine la facilité avec laquelle l'application pourra être maintenue, testée et étendue. Aujourd'hui, nous allons analyser les trois approches les plus populaires : MVC, MVVM et VIPER. Pas de théorie sèche — seulement du code vivant et des conseils pratiques.

Si vous codez en Swift mais que vous utilisez encore "tout dans un seul fichier" — cet article est pour vous. C'est parti !

MVC (Model-View-Controller) — le classique du genre

MVC est le modèle qu'Apple met à la base d'UIKit. Cela semble simple : Model gère les données, View gère l'affichage, Controller les relie. Mais en pratique, MVC dans iOS se transforme souvent en Massive View Controller — un contrôleur qui sait tout, fait tout et pèse des milliers de lignes.

Cependant, si l'on respecte la discipline, MVC fonctionne parfaitement. Voici un exemple d'application simple pour afficher une liste d'utilisateurs.

// Model\nstruct User {\n    let name: String\n    let email: String\n}\n\n// View (pas du code UI, mais un protocole pour la mise à jour)\nprotocol UserListView: AnyObject {\n    func showUsers(_ users: [User])\n    func showError(_ error: Error)\n}\n\n// Controller\nclass UserListViewController: UIViewController, UserListView {\n    \n    @IBOutlet weak var tableView: UITableView!\n    private var users: [User] = []\n    private let dataService = DataService()\n    \n    override func viewDidLoad() {\n        super.viewDidLoad()\n        tableView.dataSource = self\n        loadUsers()\n    }\n    \n    func loadUsers() {\n        dataService.fetchUsers { [weak self] result in\n            switch result {\n            case .success(let users):\n                self?.showUsers(users)\n            case .failure(let error):\n                self?.showError(error)\n            }\n        }\n    }\n    \n    func showUsers(_ users: [User]) {\n        self.users = users\n        tableView.reloadData()\n    }\n    \n    func showError(_ error: Error) {\n        let alert = UIAlertController(title: "Erreur", message: error.localizedDescription, preferredStyle: .alert)\n        alert.addAction(UIAlertAction(title: "OK", style: .default))\n        present(alert, animated: true)\n    }\n}\n\nextension UserListViewController: UITableViewDataSource {\n    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {\n        return users.count\n    }\n    \n    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {\n        let cell = tableView.dequeueReusableCell(withIdentifier: "UserCell", for: indexPath)\n        let user = users[indexPath.row]\n        cell.textLabel?.text = user.name\n        cell.detailTextLabel?.text = user.email\n        return cell\n    }\n}

Avantages du MVC :

\n
• Simplicité et clarté — chaque nouveau développeur comprend rapidement.
\n
• Support natif d'Apple — pas besoin d'ajouter de bibliothèques tierces.
\n
• Démarrage rapide pour les petits projets.
\n

Inconvénients du MVC :

\n
• Les contrôleurs deviennent "lourds" et difficiles à tester.
\n
• Difficile de réutiliser la logique entre différents écrans.
\n
• Lorsque le projet grandit, le code se transforme en spaghettis.
\n

Conclusion : MVC est bon pour les applications simples ou les prototypes. Si vous savez que le projet va grandir — tournez-vous vers MVVM ou VIPER.

MVVM (Model-View-ViewModel) — le standard moderne

MVVM résout le problème principal du MVC — il décharge le contrôleur. Toute la logique métier et la préparation des données pour l'affichage sont déplacées dans le ViewModel. La View (contrôleur) se contente de s'abonner aux changements