Modelo-Vista-Controlador (MVC): entrada, actualización, renderizado
El patrón Modelo-Vista-Controlador en un lienzo interactivo: cómo la entrada del usuario llega al controlador, actualiza el modelo y se renderiza a través de la vista.
MVC separa una aplicación en tres partes con una sola regla: el controlador gestiona la entrada, el modelo es dueño del estado y de las reglas, y la vista renderiza el modelo; ni la vista ni el controlador tocan el estado directamente.
Modelo-Vista-Controlador (MVC): entrada, actualización, renderizado
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Sigue el bucle en el orden en que lo dibujan las flechas: del usuario al controlador, al modelo, a la vista y de vuelta al usuario.
- Las tres columnas son los tres actos: llega la entrada, se actualiza el estado y se renderiza la salida.
- Los carriles son la separación de responsabilidades: cada carril es dueño de un tipo de trabajo y ningún carril hace el de otro.
Entrada
«El usuario interactúa con la interfaz» inicia el bucle, y «El controlador recibe la entrada» es el guardia de tráfico: lee la acción, decide qué significa e instruye al modelo. El comentario del controlador hace explícita la regla: él mismo no guarda ningún estado, y por eso puede atender muchas peticiones sin recordar nada.
Actualización
«El controlador actualiza el modelo» cruza al carril del modelo, y «El modelo guarda el estado y las reglas de negocio» es la definición del modelo: es la única fuente de verdad para los datos y para las reglas que los gobiernan. «El modelo notifica el cambio a los observadores» es la mitad de la notificación: el modelo no le dice a la vista qué dibujar, solo anuncia que algo ha cambiado, y pueden escuchar cuantas vistas haga falta.
Renderizado
«La vista se vuelve a renderizar desde el modelo» es el único trabajo de la vista: leer el modelo y mostrarlo. Su comentario señala la disciplina que evita que MVC se derrumbe: la vista nunca cambia los datos, solo pregunta y muestra. «El usuario ve la interfaz actualizada» cierra el círculo de vuelta en la fila del usuario, que es donde empieza y termina cada interacción.
Relaciones clave y conclusiones
- El controlador gestiona la entrada, el modelo es dueño del estado y la vista renderiza: tres responsabilidades, tres carriles.
- Ni la vista ni el controlador escriben datos; todos los cambios pasan por el modelo.
- El modelo notifica a los observadores en lugar de mandar sobre la vista, así que un mismo modelo puede alimentar muchas vistas.
- La separación hace que cada parte se pueda probar por separado: la recompensa original del patrón.
- MVC es el antecesor de muchos patrones modernos (MVVM, MVP, los stores al estilo Redux), y todos conservan la misma separación.
Cuándo usar este diagrama
- Presentar el patrón a alguien que desarrolla antes de que lea la documentación de un framework: el triángulo es el mapa que implementa cualquier framework.
- Explicar por qué un código es difícil de cambiar: gestionar el estado en la vista es una violación de MVC, y se ve en el lienzo.
- Comparar MVC con las arquitecturas por capas del diagrama de la arquitectura limpia.
Cómo funciona
Lleva tu framework al triángulo
Renombra las tres cajas con las piezas reales de tu framework —un fichero de rutas como controlador, tus modelos del ORM como modelo, tus plantillas como vista— para que el patrón sea concreto.
Añade el paso del router
Inserta un paso de enrutamiento entre el usuario y el controlador si tu framework tiene uno, conectado con el controlador al que despacha.
Muestra varias vistas
Añade una segunda caja de vista, escuchando las dos al mismo modelo —una lista y una vista de detalle—, para demostrar la relación de observador en la que se apoya el patrón.
Añade la capa de persistencia
Amplía el modelo con un paso de base de datos, anotando que el modelo es su dueño y que el controlador y la vista nunca la tocan directamente.
Preguntas frecuentes
¿Qué es MVC?
MVC —Modelo-Vista-Controlador— es un patrón de software que separa una aplicación en tres partes: el controlador gestiona la entrada, el modelo es dueño de los datos y de las reglas de negocio, y la vista renderiza el modelo. La ventaja de la separación es que cada parte se puede desarrollar y probar de forma independiente, y que un mismo modelo se puede mostrar en muchas vistas. Es el patrón sobre el que están construidos la mayoría de los frameworks web.
¿Por qué el modelo es el centro de MVC?
Porque el modelo es la única fuente de verdad. Si tanto el controlador como la vista pudieran escribir datos, se separarían y se pelearían por el estado. Mantener todos los cambios en el modelo significa que hay exactamente un sitio donde viven las reglas de los datos, y que la vista siempre es una proyección de un modelo coherente. Por eso el diagrama coloca las dos cajas del modelo en su propio carril.
¿Qué pasa si pongo lógica en la vista?
Obtienes un antipatrón que a veces se llama «vista gorda»: código de presentación mezclado con reglas de negocio, que no se puede probar sin renderizar y que se separa del modelo. La misma crítica vale para un controlador que guarda lógica de negocio en lugar de delegarla. La disciplina de MVC es que cada carril se quede en su carril: las tres filas separadas del diagrama son esa regla hecha visible.
¿Qué relación tiene MVC con los frameworks modernos?
La mayoría de los frameworks modernos conservan el triángulo con nombres nuevos: MVVM añade una capa de modelo de vista, MVP le da un presentador a la vista y las bibliotecas de gestión de estado como Redux son en esencia el modelo con una regla de notificación más estricta. El bucle central del lienzo —la entrada cambia el estado, el estado dirige la salida— es el invariante que conserva cada uno de ellos.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo de MVC como tu propio diagrama, renombra las cajas con las de tu framework y traza tu propio camino de la petición.