Module 9 – Architecture & bonnes pratiques PHP

Niveau 2 – PHP avancé

Objectifs

Pattern MVC, séparation des responsabilités, principes SOLID en PHP, et refactoring. Ce module prépare directement à Laravel, qui s’appuie sur ces bases.

Théorie

MVC (Model – View – Controller)

MVC sépare l’application en trois couches :

Couche	Rôle	En PHP
Model	Données et logique métier (accès BDD, règles)	Classes métier, repositories, entités
View	Affichage (HTML, formatage)	Fichiers de templates (HTML + echo / boucles)
Controller	Orchestration : reçoit la requête, appelle le Model, choisit la View, renvoie la réponse	Scripts ou classes qui traitent les actions

Flux typique :
Requête → Controller (lit les paramètres, valide) → Model (récupère/met à jour les données) → Controller (choisit la vue, passe les données) → View (génère le HTML) → Réponse.

Avantages : code plus clair, testable, évolutif. Laravel est basé sur MVC (Models Eloquent, Views Blade, Controllers).

Séparation des responsabilités

Chaque composant doit avoir une seule raison de changer (principe SRP de SOLID).
Exemples :

Une classe qui envoie des e-mails ne doit pas générer du HTML complexe.
Le Controller ne doit pas contenir de requêtes SQL brutes ; il délègue au Model (ou à un Repository).
La View ne doit pas faire d’accès BDD ni de logique métier lourde ; elle reçoit des données déjà prêtes.

SOLID (adapté PHP)

S – Single Responsibility : une classe, une responsabilité.
O – Open/Closed : ouvert à l’extension (nouvelles classes), fermé à la modification du code existant (éviter de casser l’existant).
L – Liskov Substitution : les sous-classes doivent pouvoir remplacer la classe parente sans casser le contrat (comportement attendu).
I – Interface Segregation : interfaces petites et ciblées plutôt qu’une grosse interface.
D – Dependency Inversion : dépendre d’abstractions (interfaces) plutôt que de classes concrètes ; les dépendances sont injectées (constructeur) au lieu d’être créées dans la classe.

En PHP : typer les dépendances par interface, injection par constructeur, éviter new dans les classes métier pour les services (préférer l’injection).

Refactoring

Refactoring = modifier le code pour en améliorer la structure sans changer le comportement (idéalement avec des tests pour vérifier).

Pratiques courantes :

Extraire des méthodes ou des classes pour réduire la longueur et clarifier l’intention.
Renommer variables/méthodes pour plus de clarté.
Remplacer des conditions complexes par du polymorphisme ou des stratégies.
Introduire des interfaces pour découpler les implémentations.

Exemple de structure MVC simple (sans framework)

app/
├── Controller/
│   └── UserController.php   → reçoit requête, appelle UserRepository, charge la vue
├── Model/
│   └── UserRepository.php   → requêtes SQL / PDO
├── View/
│   └── user/
│       └── show.php         → HTML + variables passées par le controller
public/
└── index.php               → front controller, route vers le bon controller

UserController (simplifié) :

class UserController {
    public function __construct(private UserRepository $repo) {}
    public function show(int $id): void {
        $user = $this->repo->find($id);
        if ($user === null) {
            http_response_code(404);
            return;
        }
        require __DIR__ . "/../View/user/show.php";
    }
}

View (show.php) :
Recevoir $user et afficher uniquement avec htmlspecialchars pour les sorties.

Bonnes pratiques

Controller fin : pas de SQL, pas de HTML ; il orchestre.
Model / Repository : tout l’accès aux données et la logique métier associée.
View : uniquement affichage et boucles simples ; pas de logique métier.
Dépendances : injecter par constructeur, typer avec des interfaces quand c’est pertinent.
Refactoring progressif : petits pas, tests si possible.

Quiz – Module 9

Q1. Quel est le rôle de chaque couche dans MVC ?
Q2. Où doit se trouver la logique d’accès à la base de données ?
Q3. Que signifie « Single Responsibility » ?
Q4. Qu’est-ce que le refactoring ?
Q5. Pourquoi Laravel est-il plus facile à aborder après avoir vu MVC en PHP natif ?

Réponses

R1. Model : données et logique métier. View : affichage (HTML). Controller : reçoit la requête, utilise le Model, choisit la View et renvoie la réponse.

R2. Dans le Model (ou des classes dédiées type Repository), pas dans le Controller ni la View.

R3. Une classe ne doit avoir qu’une seule responsabilité (une seule raison de changer).

R4. Modifier la structure du code pour le rendre plus clair et maintenable sans en changer le comportement (idéalement avec des tests).

R5. Laravel est organisé en MVC (Models, Views Blade, Controllers) et applique les mêmes principes (séparation, injection, interfaces). Comprendre MVC en PHP natif permet de saisir la logique du framework au lieu de « faire de la magie ».

Examen PHP avancé (Niveau 2)

L’examen de fin de Niveau 2 peut porter sur :

MVC : identifier où placer une fonctionnalité (Model / View / Controller).
SOLID : expliquer SRP et Dependency Inversion avec un exemple.
PDO : écrire une requête préparée (SELECT ou INSERT).
POO : visibilité, héritage, exception personnalisée.
Sécurité : injection SQL, XSS (échappement HTML).

Réussite requise (14/20 à l’examen Niveau 2) pour débloquer le Niveau 3 – Laravel fondamental.

Suite

Niveau 3 – Laravel fondamental : Module 10 – Introduction à Laravel (installation, structure, Artisan, Composer).

Objectifs​

Théorie​

MVC (Model – View – Controller)​

Séparation des responsabilités​

SOLID (adapté PHP)​

Refactoring​

Exemple de structure MVC simple (sans framework)​

Bonnes pratiques​

Quiz – Module 9​

Examen PHP avancé (Niveau 2)​

Suite​