MV contra MVVM: el patrón que SwiftUI ya trae

Ningún debate de arquitectura en el mundo Apple ha consumido tanta tinta como este, y pocos se han discutido peor. De un lado están quienes sostienen que cada pantalla necesita su clase de modelo de vista, porque así se hacía en UIKit y así se hace en los demás ecosistemas. Del otro, quienes replican que SwiftUI ya trae su propio patrón incorporado y que envolver el estado en una capa más es reproducir la solución de un problema que ya no existe. La discusión degenera en preferencias personales porque casi nunca se hace la pregunta previa, que es histórica antes que técnica: qué trabajo concreto hacía un modelo de vista en el mundo imperativo, y cuánto de ese trabajo sigue vivo ahora que el framework observa el estado por ti y recalcula la interfaz sin que nadie se lo pida.

Qué resolvía el modelo de vista en UIKit

En una arquitectura imperativa, la pantalla es un objeto de larga vida con estado interno mutable, y alguien tiene que sincronizar ese estado con lo que se ve. Ese alguien era el controlador, y el modelo de vista nació para quitarle trabajo: guardaba los datos ya formateados y ofrecía un mecanismo de notificación para que la capa de interfaz supiera cuándo volver a pintarse.

// Mundo imperativo: alguien debe empujar cada cambio hacia la pantalla
final class PerfilViewModel {
    var nombreFormateado: String = "" { didSet { onChange?() } }
    var onChange: (() -> Void)?
}

final class PerfilViewController: UIViewController {
    let vm = PerfilViewModel()
    override func viewDidLoad() {
        super.viewDidLoad()
        vm.onChange = { [weak self] in self?.render() }   // el puente manual
    }
}

Ese puente manual era el verdadero producto del patrón. El modelo de vista existía porque la interfaz no sabía recalcularse sola: había que decirle cuándo, y había que decírselo sin que la vista conociera la red ni la base de datos. Cuando el puente desaparece, la justificación original desaparece con él, y lo que quede en pie tendrá que justificarse por otros motivos.

El patrón MV: la vista ya es el observador

Una View de SwiftUI no es un objeto que vive y se actualiza: es un valor efímero que el runtime construye, compara y descarta. Su body es una función pura del estado, y el sistema de observación decide cuándo volver a evaluarla. Bajo esa premisa, el modelo con lógica y las vistas que lo leen bastan: eso es lo que la comunidad llama patrón MV.

@Observable
final class Biblioteca {
    var libros: [Libro] = []
    var pendientes: [Libro] { libros.filter { !$0.leido } }
    func marcarLeido(_ id: Libro.ID) {
        guard let i = libros.firstIndex(where: { $0.id == id }) else { return }
        libros[i].leido = true
    }
}

struct BibliotecaView: View {
    @Environment(Biblioteca.self) private var biblioteca
    var body: some View {
        List(biblioteca.pendientes) { libro in
            Text(libro.titulo)
        }
    }
}

El argumento a favor de conservar el modelo de vista

El bando contrario no defiende la ceremonia por la ceremonia. Su tesis es que el estado de presentación existe aunque el framework observe solo: el texto a medio escribir de un formulario, el error de validación, el indicador de carga o el destino de navegación no pertenecen al dominio, y meterlos en el modelo compartido lo contamina. Un modelo de vista es entonces un modelo más, uno cuyo dominio es la pantalla.

// Estado de pantalla que no pertenece al dominio
@Observable
final class AltaViewModel {
    var email = ""
    var repetir = ""
    var aceptaTerminos = false
    private(set) var enviando = false

    var emailValido: Bool { email.contains("@") && email.contains(".") }
    var coinciden: Bool { !repetir.isEmpty && email == repetir }
    var puedeEnviar: Bool { emailValido && coinciden && aceptaTerminos && !enviando }
}

Ninguna de esas cuatro propiedades tiene sentido fuera de esta pantalla, y ninguna debería vivir en el modelo de la aplicación. Meterlas ahí sería el error simétrico del que se acusa al bando contrario: contaminar el dominio con el vocabulario de una interfaz concreta.

La honestidad exige reconocer que ambos bandos tienen razón en su terreno. Una pantalla que muestra una lista y navega no gana nada con una capa extra. Un formulario de alta con siete campos, validación cruzada, envío asíncrono y estados de error diferenciados sí gana, y quien lo niega termina con un body de doscientas líneas que ninguna prueba puede tocar.

flowchart TD
E[Cambia el estado observable] --> R[El runtime invalida las vistas dependientes]
R --> B[Se reevalua el body como funcion pura]
B --> D[SwiftUI difunde el arbol y actualiza la pantalla]
V[Modelo de vista clasico] -.-> N[Notificar a mano cuando repintar]
N -.-> X[Trabajo que el runtime ya hace por ti]
style D fill:#a6e3a1,color:#11111b
style X fill:#f38ba8,color:#11111b

Cómo se decide sin doctrina

El error de método consiste en elegir el patrón antes de conocer la pantalla. La decisión es local: se toma vista a vista, se revisa cuando la vista crece y no compromete a las demás. Un proyecto sano puede tener treinta pantallas en MV puro y cuatro con modelo de vista, y esa mezcla no es incoherencia sino proporción. Lo incoherente es la regla uniforme aplicada sin mirar, en cualquiera de las dos direcciones.

Hay además un matiz que casi siempre disuelve la discusión antes de que empiece: el debate confunde dos ejes distintos. Uno es dónde vive el estado de presentación, que es lo que MV y MVVM discuten de verdad. El otro es si el dominio está separado del transporte, que es una cuestión independiente y bastante más importante. Una app puede ser MV puro y estar impecablemente estratificada, y otra puede tener un modelo de vista por pantalla y llamar a la red desde dentro de todos ellos. La segunda tiene un problema grave que ningún patrón de presentación resuelve, y sin embargo la discusión pública dedica cien veces más energía al primer eje que al segundo.