![Imagen de portada de [Arquitectura iOS #4] Diferencias entre MVP y MVVM](/assets/images/posts/4b118d20-6c27-4d0a-ad4a-7ec1b68ffb16/1.jpg)
Hay una pregunta recurrente en las entrevistas sobre arquitectura iOS.
«¿Cuál es la diferencia entre MVP y MVVM?»
Ambos patrones aligeran los controladores de vista y colocan un objeto intermedio (Presenter/ViewModel) en el centro. Si solo miras el diagrama, parece que cambia el nombre de una caja, así que responder resulta sorprendentemente difícil.
Hoy resumiremos la diferencia con un único criterio: «¿el objeto intermedio conoce la View o no?»
MVP: el Presenter da órdenes a la View
En MVP (Model-View-Presenter), el Presenter conoce la View. Más exactamente, referencia el protocolo (interfaz) que implementa la View.
protocol ProfileViewProtocol: AnyObject {
func showName(_ name: String)
func showLoading(_ isLoading: Bool)
}
final class ProfilePresenter {
weak var view: ProfileViewProtocol?
func load() {
view?.showLoading(true)
// ...Después de cargar los datos
view?.showName("Juan Pérez")
view?.showLoading(false)
}
}¿Se ve el flujo? Tras procesar los datos, el Presenter ordena directamente a la view: «Muestra esto». La View (controlador de vista) implementa los métodos del protocolo y solo tiene que dibujar lo indicado.
- Ventaja: el flujo es explícito y fácil de seguir, sin necesidad de un framework de binding.
- Desventaja: cuantos más elementos tenga la pantalla, más métodos del protocolo aparecen.
showName,showAge,showBadge…
MVVM: el ViewModel no conoce la existencia de la View
En cambio, el ViewModel de MVVM (Model-View-ViewModel) no referencia la View. Solo mantiene el estado.
final class ProfileViewModel {
@Published private(set) var displayName = ""
@Published private(set) var isLoading = false
func load() {
isLoading = true
// ...Después de cargar los datos
displayName = "Juan Pérez"
isLoading = false
}
}No existe una llamada como view?.showName(...). El ViewModel solo actualiza su estado y la View se suscribe a ese estado (binding) para dibujarlo automáticamente. La dirección de las órdenes se invierte.
- MVP: empuja datos hacia la View
- MVVM: la View observa el ViewModel para obtener los datos
Por eso MVVM requiere prácticamente un mecanismo de binding (Combine, @Observable, etc.). En el artículo anterior explicamos en detalle por qué un MVVM sin binding queda incompleto.
La diferencia queda clara al ver el código de pruebas
Ambos patrones buscan «probar la lógica sin una pantalla», pero el enfoque de prueba es diferente.
Las pruebas de MVP deben crear una View falsa y registrar las llamadas.
final class MockView: ProfileViewProtocol {
var shownName: String?
func showName(_ name: String) { shownName = name }
func showLoading(_ isLoading: Bool) {}
}
// presenter.load() después mockView.shownName verificaciónEn las pruebas de MVVM basta con comprobar los valores del estado, sin mocks.
let vm = ProfileViewModel()
vm.load()
#expect(vm.displayName == "Juan Pérez")No hacen falta protocolos ni objetos mock. Es un beneficio práctico de que el ViewModel no conozca la View.
Entonces, ¿cuál deberías usar?
El criterio es sorprendentemente simple: si existe de forma natural un mecanismo de binding.
- SwiftUI, o UIKit con Combine → MVVM es lo natural. El binding viene incluido.
- UIKit heredado donde introducir binding resulta costoso → MVP es más práctico. Funciona solo con protocolos, el flujo es explícito y la incorporación es sencilla.
Que MVVM se haya convertido prácticamente en el estándar de iOS moderno se debe menos a que sea superior a MVP y más a que Combine y @Observable se ofrecen a nivel de framework, eliminando la única barrera de entrada de MVVM: el binding.
Resumen
- La diferencia esencial entre MVP y MVVM es una sola. El Presenter conoce la View (protocolo) y le da órdenes directamente; el ViewModel no conoce la View y solo expone el estado.
- Por eso MVP no necesita binding, mientras que MVVM lo requiere.
- En las pruebas, MVP necesita una View mock y MVVM termina con la verificación del estado.
- Si el entorno ofrece binding gratis (SwiftUI·Combine), usa MVVM; si no, MVP también es una opción muy válida.
En el próximo artículo trataremos VIPER, el extremo de la separación modular que lleva esta idea un paso más allá. También veremos por qué las aplicaciones grandes lo adoptaron y por qué lo abandonaron.