Modèles architecturaux en PHP : du chaos au clean code

Arrêtez d'écrire des "spaghettis" : pourquoi les modèles architecturaux en PHP sont indispensables

Avez-vous déjà ouvert un ancien projet PHP et ressenti un frisson dans le dos ? Quand dans un seul fichier index.php sont mélangés des requêtes SQL, du HTML, de la logique métier et des prières aux dieux anciens ? Si oui — vous avez rencontré une absence d'architecture. Ou pire encore, un chaos architectural.

Aujourd'hui, nous allons parler de la façon dont les modèles architecturaux en PHP transforment votre code d'un tas de briques en un bâtiment structuré. Ce n'est pas une théorie réservée aux seniors avec 10 ans d'expérience. Ce sont des outils qui sauveront votre sommeil et le budget du projet. Nous allons analyser 4 modèles clés : MVC, Active Record, Repository et Dependency Injection. C'est parti !

MVC (Model-View-Controller) : le fondement de tout framework

Si vous avez travaillé avec Laravel, Symfony ou Yii2 — vous avez déjà vu le MVC. Ce n'est pas qu'un acronyme, mais une façon de diviser le code en trois zones de responsabilité :

\n
• Model — les données et la logique métier (travail avec la BDD, validation).
\n
• View — l'affichage (HTML, templates).
\n
• Controller — le traitement des requêtes (lien de connexion).
\n

Voici à quoi cela ressemble en PHP pur (sans framework) :

<?php\n// UserController.php\nclass UserController {\n    public function show(int $id): void {\n        $userModel = new UserModel();\n        $user = $userModel->findById($id); // Model\n        \n        // View\n        include 'views/user_profile.php';\n    }\n}\n\n// UserModel.php\nclass UserModel {\n    public function findById(int $id): ?array {\n        $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");\n        $stmt->execute([$id]);\n        return $stmt->fetch() ?: null;\n    }\n}\n\n// views/user_profile.php\n<h1><?= htmlspecialchars($user['name']) ?></h1>

Quand l'appliquer : Toujours, lorsque vous avez plus de 2 pages. MVC est la base. Il permet la séparation de la logique, simplifie les tests et la maintenance.

Astuce : N'écrivez pas de SQL directement dans la View. Cela tue toute l'essence du modèle. Utilisez des templates préparés (Twig, Blade) — ils échappent automatiquement la sortie, protégeant contre les XSS.

Active Record : la simplicité qui se paie en performances

Active Record — c'est quand un objet représente à la fois une ligne dans la BDD et contient des méthodes pour travailler avec elle. Classique : Eloquent dans Laravel ou ActiveRecord dans Yii2.

Exemple en PHP pur :

<?php\nclass User extends ActiveRecord {\n    protected string $table = 'users';\n    \n    public static function findByName(string $name): ?self {\n        return self::query()\n            ->where('name', $name)\n            ->first();\n    }\n}\n\n// Utilisation\n$user = new User();\n$user->name = 'Ivan';\n$user->email = 'ivan@example.com';\n$user->save(); // INSERT dans la BDD\n\n$admin = User::findByName('Admin');\n$admin->role = 'superadmin';\n$admin->update();

Avantages :

\n
• Minimum de code pour les opérations CRUD.
\n
• Intuitif pour les débutants.
\n

Inconvénients :

\n
• Viole le Principe de Responsabilité Unique (un seul objet fait tout).
\n
• Difficile à tester — l'objet est fortement couplé à la BDD.
\n
• Mauvaise évolutivité pour une logique complexe.
\n

Conclusion : Active Record est un excellent choix pour les prototypes, les petits projets et les panneaux d'administration. Mais pour les applications d'entreprise, il vaut mieux se tourner vers Repository.

Repository : abstraction sur le stockage de données

Repository — c'est une couche entre la logique métier et la source de données (BDD, API, fichiers). Vous dites : « Donne-moi l'utilisateur p