Patrones arquitectónicos en Swift: MVC, MVVM y VIPER con ejemplos

Patrones arquitectónicos en Swift: del caos al orden

Cada desarrollador iOS, tarde o temprano, se enfrenta a la pregunta: "¿Cómo organizar el código para que el proyecto no se convierta en un espagueti en seis meses?" La respuesta es simple: los patrones arquitectónicos. En Swift, como en cualquier otro lenguaje, la elección de la arquitectura determina lo fácil que será mantener, probar y ampliar la aplicación. Hoy analizaremos los tres enfoques más populares: MVC, MVVM y VIPER. Nada de teoría seca, solo código vivo y consejos prácticos.

Si escribes en Swift pero todavía usas "todo en un solo archivo", este artículo es para ti. ¡Allá vamos!

MVC (Model-View-Controller) — el clásico del género

MVC es el patrón que Apple incorpora en la base de UIKit. Parece sencillo: Model se encarga de los datos, View de la visualización y Controller los conecta. Pero en la práctica, MVC en iOS a menudo se convierte en Massive View Controller: un controlador que lo sabe todo, lo hace todo y pesa miles de líneas.

Sin embargo, si se mantiene la disciplina, MVC funciona perfectamente. Aquí tienes un ejemplo de una aplicación simple para mostrar una lista de usuarios.

// Model\nstruct User {\n    let name: String\n    let email: String\n}\n\n// View (no es código de UI, sino un protocolo para actualizar)\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: "Error", 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}

Ventajas de MVC:

\n
• Simplicidad y claridad: cualquier desarrollador nuevo se adapta rápidamente.
\n
• Soporte nativo de Apple: no es necesario agregar bibliotecas externas.
\n
• Inicio rápido para proyectos pequeños.
\n

Desventajas de MVC:

\n
• Los controladores se vuelven "gordos" y difíciles de probar.
\n
• Es difícil reutilizar la lógica entre diferentes pantallas.
\n
• Al crecer el proyecto, el código se convierte en espagueti.
\n

Conclusión: MVC es bueno para aplicaciones simples o prototipos. Si sabes que el proyecto va a crecer, mira hacia MVVM o VIPER.

MVVM (Model-View-ViewModel) — el estándar moderno

MVVM resuelve el principal problema de MVC: descarga al controlador. Toda la lógica de negocio y la preparación de datos para la visualización se trasladan a la ViewModel. La View (controlador) solo se suscribe a los cambios