4.1Entender el patrón MVC
Lo esencial en 30 segundos
- MVC = 3 responsabilidades separadas : el Modelo gestiona datos y lógica de negocio, la Vista muestra el HTML, el Controlador orquesta (petición → modelo → vista).
- Flujo típico : petición → enrutamiento hacia el controlador adecuado → el controlador llama al modelo → el modelo devuelve los datos → el controlador elige la vista.
- Reflejo de Riad : controladores ligeros, modelos ricos — nunca consultas SQL en las vistas, nunca lógica de negocio en la presentación.
Minicaso seguido — Riad ordena su catálogo en Constantine
Riad, desarrollador web en Constantine, mantiene el catálogo de una tienda local : su archivo mezcla consultas SQL, cálculos de precios y HTML, y cada cambio rompe otra cosa. Decide ordenar : un modelo que recupera los productos por categoría, un controlador que orquesta la página « productos », una vista que muestra la lista recibida. Cuando el cliente pide una nueva presentación, Riad solo toca la vista ; cuando cambia la regla de precios, solo toca el modelo. Primer hito del hilo : del PHP « desordenado » al PHP con arquitectura.
Este mismo caso vuelve en el curso, el esquema, el guion y el desafío 48h — y continúa en 4.2, 4.3, 4.4 y 4.5.
1. Las tres responsabilidades
El MVC (Modelo-Vista-Controlador) separa la aplicación en tres capas. El Modelo gestiona los DATOS y la LÓGICA DE NEGOCIO : acceso a la base, entidades (Producto, Usuario), reglas (precio con descuento, correo único) — independientemente de la presentación. La Vista gestiona la PRESENTACIÓN : HTML con inserciones mínimas (mostrar una variable, iterar una lista), sin lógica de negocio ni acceso a la base. El Controlador hace de ENLACE : recibe la petición, llama al modelo, prepara los datos y luego elige la vista. Como Riad, apuntamos a controladores « ligeros » y modelos « ricos ».
La regla de oro : cada fragmento de código tiene UN lugar evidente. ¿Dato o regla de negocio? Modelo. ¿HTML? Vista. ¿Coordinación petición → datos → presentación? Controlador. Esta claridad elimina el « código espagueti » donde todo está mezclado en un solo archivo.
2. El flujo de una petición y los beneficios
El flujo típico : (1) el usuario pide una URL ; (2) el enrutamiento dirige al CONTROLADOR adecuado y su método ; (3) el controlador llama al MODELO (p. ej. recuperar los productos) ; (4) el controlador pasa los datos a la VISTA ; (5) la vista genera el HTML. Riad sigue este camino para cada página en lugar de hacerlo todo en un solo script.
Los beneficios : claridad (sabemos dónde encontrar qué), mantenibilidad (cambiar la vista sin tocar los datos, y viceversa), reutilización y test (los mismos modelos sirven una página HTML o una API JSON), colaboración (cada uno trabaja en su capa). Es el patrón DOMINANTE de los frameworks (Laravel, Symfony) : carpetas Models, Controllers, vistas/plantillas y enrutamiento — entenderlo ANTES de un framework es usarlo con criterio en lugar de imitarlo a ciegas.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — La lista de productos en MVC
El reparto de Riad para la página del catálogo :
Modelo → Produit::recupererParCategorie($cat) // SQL + reglas aquí
Controlador → $produits = Produit::recupererParCategorie($cat);
afficherVue('liste', ['produits' => $produits]);
Vista → foreach ($produits as $p) { mostrar $p['nom'], $p['prix'] }
Regla → cambiar la presentación = tocar solo la vistaLectura : tres bloques, tres roles, un solo sentido de circulación.
Lección : la vista recibe datos listos, no los fabrica.
Vocabulario de la sección
- MVC (Modelo-Vista-Controlador)
- Patrón de arquitectura que separa la aplicación en tres responsabilidades : Modelo (datos/lógica de negocio), Vista (presentación), Controlador (coordinación). La base de los frameworks web.
Ejemplo sencillo: Riad ordena su catálogo : modelo para los productos, vista para el HTML, controlador para orquestar.
Lo que no es: un único script mezclando SQL, cálculos y HTML.
Reflejo: para cada línea de código, preguntar : ¿dato, presentación o coordinación?
- Modelo (Model)
- Gestiona los DATOS y la LÓGICA DE NEGOCIO : acceso a la base, entidades, reglas — independientemente de la presentación.
Ejemplo sencillo: El modelo Producto de Riad recupera los productos y calcula el precio con descuento.
Lo que no es: una consulta SQL escrita en una plantilla de presentación.
Reflejo: toda regla de negocio vive en el modelo, testeable sin HTML.
- Vista (View)
- Gestiona la PRESENTACIÓN : el HTML, lo que ve el usuario ; recibe datos preparados y los presenta.
Ejemplo sencillo: La vista lista de Riad itera los productos recibidos y los muestra escapados.
Lo que no es: una plantilla que consulta la base o aplica descuentos.
Reflejo: vista « simple » : mostrar, iterar, condición simple — nada más.
- Controlador (Controller)
- Hace de ENLACE : recibe la petición, llama al modelo, elige la vista con los datos ; orquesta, ligero y legible.
Ejemplo sencillo: El controlador catálogo de Riad recupera los productos y luego muestra la vista lista.
Lo que no es: un controlador de 300 líneas que hace SQL + cálculos + HTML.
Reflejo: controlador ligero : coordinar, delegar, mostrar.
- Enrutamiento / flujo MVC
- El enrutamiento dirige la petición al controlador adecuado ; flujo : petición → enrutamiento → controlador → modelo → vista.
Ejemplo sencillo: La URL /produits de Riad llega al controlador catálogo, método index.
Lo que no es: un archivo por URL sin coordinación central.
Reflejo: seguir el flujo en cada depuración : ¿dónde se rompe la cadena?
En la práctica — En la práctica — Entender y aplicar el MVC
- Identificad las tres responsabilidades : Modelo (datos/lógica), Vista (presentación HTML), Controlador (coordinación) — y por qué separarlas.
- Seguid el flujo de una petición : petición → enrutamiento → controlador → modelo (datos) → vista (presentación).
- En un pequeño ejemplo (la lista de productos de Riad), repartid el código : modelo que recupera, controlador que llama, vista que muestra.
- Constatad los beneficios : cambiad la vista sin tocar el modelo, y viceversa — claridad, mantenibilidad, test.
Guion listo para decir — explicar su orden MVC (30 s)
« Soy Riad : saqué las consultas y las reglas de precios al modelo, el HTML a la vista, y el controlador solo orquesta — petición, modelo, vista. Resultado : cambio la presentación sin tocar los datos, y puedo probar la lógica sin navegador. »
Para decir en revisión de código ; mostrad los tres archivos lado a lado.
Modelo copiar-pegar — mini-MVC en PHP puro (código probado)
prepare('SELECT nom, prix FROM produits WHERE categorie = :cat');
$stmt->execute(['cat' => $cat]);
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
public static function prixRemise(float $prix, float $taux): float {
return round($prix * (1 - $taux), 2);
}
}
// --- Controlador : ligero, solo orquesta ---
function indexCatalogue(PDO $pdo, string $cat): void {
$produits = Produit::recupererParCategorie($pdo, $cat);
afficherVue('liste', ['produits' => $produits]); // elige la vista
}
// --- Vista : simple, solo muestra (datos ya listos, escapados) ---
function afficherVue(string $nom, array $vars): void {
$produits = $vars['produits'];
foreach ($produits as $p) {
echo '' . htmlspecialchars($p['nom']) . ' — ' . htmlspecialchars((string) $p['prix']) . ' DA ';
}
}
Pequeño script personal
Una separación ligera (3 funciones o 3 archivos) basta, pero mantened la disciplina : ninguna consulta en la presentación.
Proyecto de equipo
Como Riad : carpetas models/, controllers/, views/ — cada uno sabe dónde trabajar sin conflictos.
Mismos modelos, dos salidas
Reutilizad el modelo para una página HTML y para una API JSON : solo cambia la vista.
Antes de un framework
Practicad este reparto en PHP puro : Laravel y Symfony resultarán evidentes en lugar de mágicos.
✓ Buenas prácticas
- Separar los 3 roles : datos, presentación, coordinación.
- Apuntar a controladores ligeros y modelos ricos.
- Entender el MVC antes de abordar un framework.
✗ Errores frecuentes
- Poner consultas SQL en las vistas.
- Poner la lógica de negocio en los controladores.
- Reproducir espagueti DENTRO del framework.
Puntos clave
- MVC = 3 responsabilidades : MODELO (datos + lógica de negocio), VISTA (presentación HTML), CONTROLADOR (coordinación petición → modelo → vista).
- FLUJO : petición → ENRUTAMIENTO (controlador adecuado) → CONTROLADOR → MODELO (datos) → VISTA (presentación).
- BENEFICIOS : claridad, mantenibilidad, reutilización/test, colaboración.
- Entender el MVC ANTES de un framework = usarlo con criterio. Paso del PHP « desordenado » al PHP CON ARQUITECTURA.
Desafío 48h — aplicad mañana
Tomad 1 página mezclada y divididla en modelo + controlador + vista : el modelo recupera, el controlador orquesta, la vista muestra.
- Puedo citar las 3 capas y sus roles.
- Sé seguir el flujo de una petición.
- He dividido 1 página en MVC limpio.
Preguntas frecuentes
¿Por qué entender el MVC antes de aprender directamente un framework?
Porque los frameworks imponen una estructura MVC (carpetas Models, Controllers, vistas, enrutamiento) : sin entender el PORQUÉ, imitamos los tutoriales sin saber dónde poner qué, mezclamos las responsabilidades DENTRO del framework, y nos perdemos en cuanto salimos del caso del tutorial. Con el MVC entendido, la estructura resulta evidente, respetamos la separación (beneficios preservados), depuramos siguiendo el flujo, y los conceptos se transfieren (Laravel, Symfony y más allá).
¿Cómo repartir concretamente el código — y qué errores evitar?
Modelo : acceso a la base (CRUD), entidades, reglas de negocio — independiente de la presentación. Vista : HTML + inserciones mínimas de datos ya preparados (bucle, presentación escapada), nunca SQL ni reglas. Controlador : recibe la petición, llama al modelo, elige la vista — orquesta, ligero. Errores clásicos : consultas en las vistas, lógica de negocio en los controladores, controladores de 300 líneas. Vistas « simples », modelos « ricos », controladores « ligeros ».
¿Dónde colocar la lógica de negocio y el acceso a la base?