4.1Comprendre le pattern MVC
L'essentiel en 30 secondes
- MVC = 3 responsabilités séparées : le Modèle gère données et logique métier, la Vue affiche le HTML, le Contrôleur orchestre (requête → modèle → vue).
- Flux type : requête → routage vers le bon contrôleur → contrôleur appelle le modèle → modèle renvoie les données → contrôleur choisit la vue.
- Réflexe de Riad : contrôleurs minces, modèles riches — jamais de requêtes SQL dans les vues, jamais de logique métier dans l'affichage.
Mini-cas filé — Riad range son catalogue à Constantine
Riad, développeur web à Constantine, maintient le catalogue d'une boutique locale : son fichier mélange requêtes SQL, calculs de prix et HTML, et chaque modification casse autre chose. Il décide de ranger : un modèle qui récupère les produits par catégorie, un contrôleur qui orchestre la page « produits », une vue qui affiche la liste reçue. Quand le client demande un nouvel affichage, Riad ne touche qu'à la vue ; quand la règle de prix change, il ne touche qu'au modèle. Premier jalon du fil rouge : du PHP « en vrac » au PHP architecturé.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 4.2, 4.3, 4.4 et 4.5.
1. Les trois responsabilités
Le MVC (Modèle-Vue-Contrôleur) sépare l'application en trois couches. Le Modèle gère les DONNÉES et la LOGIQUE MÉTIER : accès base, entités (Produit, Utilisateur), règles (prix remisé, e-mail unique) — indépendamment de l'affichage. La Vue gère l'AFFICHAGE : du HTML avec des insertions minimales (afficher une variable, boucler sur une liste), sans logique métier ni accès base. Le Contrôleur fait le LIEN : il reçoit la requête, appelle le modèle, prépare les données, puis choisit la vue. Comme Riad, on vise des contrôleurs « minces » et des modèles « riches ».
La règle d'or : chaque morceau de code a UNE place évidente. Donnée ou règle métier ? Modèle. HTML ? Vue. Coordination requête → données → affichage ? Contrôleur. Cette clarté supprime le « code spaghetti » où tout est mélangé dans un seul fichier.
2. Le flux d'une requête & les bénéfices
Le flux type : (1) l'utilisateur demande une URL ; (2) le routage dirige vers le bon CONTRÔLEUR et sa méthode ; (3) le contrôleur appelle le MODÈLE (ex. récupérer les produits) ; (4) le contrôleur passe les données à la VUE ; (5) la vue génère le HTML. Riad suit ce chemin pour chaque page au lieu de tout faire dans un seul script.
Les bénéfices : clarté (on sait où trouver quoi), maintenabilité (changer la vue sans toucher aux données, et inversement), réutilisation et test (les mêmes modèles servent une page HTML ou une API JSON), collaboration (chacun travaille sur sa couche). C'est le pattern DOMINANT des frameworks (Laravel, Symfony) : dossiers Models, Controllers, vues/templates et routage — le comprendre AVANT un framework, c'est l'utiliser intelligemment au lieu de l'imiter aveuglément.
🔎 Exemple concret — 🔎 Exemple concret — La liste des produits en MVC
La répartition de Riad pour la page catalogue :
Modèle → Produit::recupererParCategorie($cat) // SQL + règles ici
Contrôleur → $produits = Produit::recupererParCategorie($cat);
afficher('liste', ['produits' => $produits]);
Vue → foreach ($produits as $p) { afficher $p['nom'], $p['prix'] }
Règle → changer l'affichage = toucher la vue seuleLecture : trois blocs, trois rôles, un seul sens de circulation.
Leçon : la vue reçoit des données prêtes, elle ne les fabrique pas.
Vocabulaire de la section
- MVC (Modèle-Vue-Contrôleur)
- Pattern d'architecture séparant l'application en trois responsabilités : Modèle (données/logique métier), Vue (affichage), Contrôleur (coordination). Le socle des frameworks web.
Exemple simple : Riad range son catalogue : modèle pour les produits, vue pour le HTML, contrôleur pour orchestre.
Ce que ce n'est pas : un unique script mélangeant SQL, calculs et HTML.
Réflexe : pour chaque ligne de code, demander : donnée, affichage ou coordination ?
- Modèle (Model)
- Gère les DONNÉES et la LOGIQUE MÉTIER : accès base, entités, règles — indépendamment de l'affichage.
Exemple simple : Le modèle Produit de Riad récupère les produits et calcule le prix remisé.
Ce que ce n'est pas : une requête SQL écrite dans un template d'affichage.
Réflexe : toute règle métier vit dans le modèle, testable sans HTML.
- Vue (View)
- Gère l'AFFICHAGE : le HTML, ce que voit l'utilisateur ; reçoit des données préparées et les présente.
Exemple simple : La vue liste de Riad boucle sur les produits reçus et les affiche échappés.
Ce que ce n'est pas : un template qui interroge la base ou applique des remises.
Réflexe : vue « bête » : afficher, boucler, condition simple — rien de plus.
- Contrôleur (Controller)
- Fait le LIEN : reçoit la requête, appelle le modèle, choisit la vue avec les données ; il orchestre, mince et lisible.
Exemple simple : Le contrôleur catalogue de Riad récupère les produits puis affiche la vue liste.
Ce que ce n'est pas : un contrôleur de 300 lignes qui fait SQL + calculs + HTML.
Réflexe : contrôleur mince : coordonner, déléguer, afficher.
- Routage / flux MVC
- Le routage dirige la requête vers le bon contrôleur ; flux : requête → routage → contrôleur → modèle → vue.
Exemple simple : L'URL /produits de Riad arrive au contrôleur catalogue, méthode index.
Ce que ce n'est pas : un fichier par URL sans coordination centrale.
Réflexe : suivre le flux à chaque débogage : où la chaîne casse-t-elle ?
En pratique — En pratique — Comprendre et appliquer le MVC
- Identifiez les trois responsabilités : Modèle (données/logique), Vue (affichage HTML), Contrôleur (coordination) — et pourquoi les séparer.
- Suivez le flux d'une requête : requête → routage → contrôleur → modèle (données) → vue (affichage).
- Sur un petit exemple (la liste de produits de Riad), répartissez le code : modèle qui récupère, contrôleur qui appelle, vue qui affiche.
- Constatez les bénéfices : changez la vue sans toucher au modèle, et inversement — clarté, maintenabilité, test.
Script prêt à dire — expliquer son rangement MVC (30 s)
« C'est Riad : j'ai sorti les requêtes et les règles de prix dans le modèle, le HTML dans la vue, et le contrôleur ne fait qu'orchestrer — requête, modèle, vue. Résultat : je change l'affichage sans toucher aux données, et je peux tester la logique sans navigateur. »
À dire en revue de code ; montrez les trois fichiers côte à côte.
Modèle copier-coller — mini-MVC en PHP pur (code testé)
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);
}
}
// --- Contrôleur : mince, il orchestre ---
function indexCatalogue(PDO $pdo, string $cat): void {
$produits = Produit::recupererParCategorie($pdo, $cat);
afficherVue('liste', ['produits' => $produits]); // choisit la vue
}
// --- Vue : bête, elle affiche (données déjà prêtes, échappées) ---
function afficherVue(string $nom, array $vars): void {
$produits = $vars['produits'];
foreach ($produits as $p) {
echo '' . htmlspecialchars($p['nom']) . ' — ' . htmlspecialchars((string) $p['prix']) . ' DA ';
}
}
Petit script perso
Une séparation légère (3 fonctions ou 3 fichiers) suffit, mais gardez la discipline : aucune requête dans l'affichage.
Projet d'équipe
Comme Riad : dossiers models/, controllers/, views/ — chacun sait où travailler sans conflit.
Même modèles, deux sorties
Réutilisez le modèle pour une page HTML et pour une API JSON : seule la vue change.
Avant un framework
Pratiquez ce découpage en PHP pur : Laravel et Symfony deviendront évidents au lieu de magiques.
✓ Bonnes pratiques
- Séparer les 3 rôles : données, affichage, coordination.
- Viser contrôleurs minces et modèles riches.
- Comprendre le MVC avant d'attaquer un framework.
✗ Pièges fréquents
- Mettre des requêtes SQL dans les vues.
- Mettre la logique métier dans les contrôleurs.
- Reproduire du spaghetti DANS le framework.
Points clés à retenir
- MVC = 3 responsabilités : MODÈLE (données + logique métier), VUE (affichage HTML), CONTRÔLEUR (coordination requête → modèle → vue).
- FLUX : requête → ROUTAGE (bon contrôleur) → CONTRÔLEUR → MODÈLE (données) → VUE (affichage).
- BÉNÉFICES : clarté, maintenabilité, réutilisation/test, collaboration.
- Comprendre le MVC AVANT un framework = l'utiliser intelligemment. Passage du PHP « en vrac » au PHP ARCHITECTURÉ.
Défi 48h — appliquez demain
Prenez 1 page mélangée et découpez-la en modèle + contrôleur + vue : le modèle récupère, le contrôleur orchestre, la vue affiche.
- Je peux citer les 3 couches et leurs rôles.
- Je sais suivre le flux d'une requête.
- J'ai découpé 1 page en MVC propre.
Questions fréquentes
Pourquoi comprendre le MVC avant d'apprendre directement un framework ?
Parce que les frameworks imposent une structure MVC (dossiers Models, Controllers, vues, routage) : sans comprendre le POURQUOI, on imite les tutoriels sans savoir où mettre quoi, on mélange les responsabilités DANS le framework, et on est perdu dès qu'on sort du cas du tutoriel. Avec le MVC compris, la structure devient évidente, on respecte la séparation (bénéfices préservés), on débogue en suivant le flux, et les concepts se transfèrent (Laravel, Symfony, et au-delà).
Comment répartir concrètement le code — et quelles erreurs éviter ?
Modèle : accès base (CRUD), entités, règles métier — indépendant de l'affichage. Vue : HTML + insertions minimales de données déjà préparées (boucle, affichage échappé), jamais de SQL ni de règles. Contrôleur : reçoit la requête, appelle le modèle, choisit la vue — il orchestre, mince. Erreurs classiques : requêtes dans les vues, logique métier dans les contrôleurs, contrôleurs de 300 lignes. Vues « bêtes », modèles « riches », contrôleurs « minces ».
Où placer la logique métier et l'accès à la base ?