Jour 12 – MVC : Créer l’architecture MVC d’un site web

Quand vous commencez à développer un site web, vous pouvez avoir envie de tout faire dans un seul fichier PHP. C’est normal au début : moins de fichiers, moins de complexité, plus simple à gérer. Mais dès que votre site grandit, cela devient vite un cauchemar. L’architecture MVC va révolutionner vos développements web.

Imaginez une maison sans pièce, où tout serait empilé au même endroit : le frigo à côté du lit, le bureau au-dessus de la baignoire… C’est un peu ce qui se passe quand on met tout son code dans un seul fichier. Résultat : on s’y perd, on fait des erreurs, on met plus de temps à corriger ou ajouter des fonctionnalités.

C’est pour cela que les développeurs utilisent des architectures, c’est-à-dire des manières intelligentes de séparer le code en plusieurs blocs, chacun ayant un rôle bien précis. L’une des plus simples et des plus utilisées s’appelle MVC, ce qui signifie :

• Modèle : pour tout ce qui touche aux données (souvent les bases de données),
• Vue : pour ce qui est visible à l’écran, ce que l’utilisateur voit,
• Contrôleur : pour faire le lien entre les deux, c’est le cerveau de votre site.

En adoptant cette structure, vous pourrez travailler de façon propre, organisée et évolutive. Aujourd’hui, nous allons mettre en place ce système pas à pas. Préparez-vous, nous allons construire les fondations solides de notre futur site : Créa-code. On code enfin !

Les études préalables sont terminées : place à ce que vous aimez vraiment… le codage ! À partir de maintenant, nous allons entrer dans le concret, avec la mise en place du site Créa-code. Pour bien suivre, il est essentiel d’avoir quelques bases en HTML, CSS, PHP et JavaScript. Pas besoin de tout maîtriser parfaitement, mais il faut au moins comprendre les grandes notions. Si c’est votre cas, vous êtes prêt pour la suite !

#100JoursPourCoder commence réellement donc dès maintenant.

Objectif du jour

À la fin de cette journée, vous aurez :

• Un projet PHP organisé selon le modèle MVC.
• Une page d’accueil dynamique fonctionnelle.
• Une base solide pour ajouter les routes, les modèles, les utilisateurs, la base de données et bien plus.

Tout cela sera fait sans framework externe, pour que vous compreniez vraiment comment ça marche sous le capot.

Arborescence du projet

Voici la structure finale que nous voulons atteindre aujourd’hui :

code-crea/
│
├── autoload.php
├── config.php
│
├── public/
│   ├── index.php
│   └── .htaccess
│
├── app/
│   ├── Controllers/
│   │   └── HomeController.php
│   ├── Models/
│   │   └── Model.php (vide pour le moment)
│   ├── Views/
│   │   └── home.php
│   └── Core/
│       ├── Controller.php
│       └── View.php (facultatif aujourd'hui)

Chaque dossier a un rôle :

• public/ contient le point d’entrée de votre site, celui que le navigateur va charger.
• app/ contient tout le code de votre application : les contrôleurs, les vues, les modèles.
• autoload.php permet de charger automatiquement les fichiers PHP.
• config.php pourra contenir vos réglages futurs (connexion à la base, etc.).

Nous allons maintenant créer tous ces dossiers et les remplir progressivement avec du code.

Étape 1 – Création du dossier de projet

Commencez par créer un dossier nommé code-crea sur votre ordinateur ou dans votre serveur local (par exemple dans htdocs si vous utilisez XAMPP ou MAMP).

À l’intérieur, créez les sous-dossiers suivants :

• public/
• app/
  • Controllers/
  • Models/
  • Views/
  • Core/

Vous pouvez le faire à la main ou avec votre éditeur de code (VS Code par exemple).

Étape 2 – Le point d’entrée du site : public/index.php

Créez le fichier suivant : public/index.php

C’est lui que le navigateur va charger en premier quand quelqu’un visite votre site. Ce fichier jouera le rôle de chef d’orchestre : il va charger les classes nécessaires, appeler le bon contrôleur, qui affichera ensuite la vue.

Pour tout comprendre de la POO (Porgrammation Orienté Objet), consultez notre tutoriel complet sur la POO en PHP.

Voici son contenu :

<?php
// On commence toujours par charger l'autoload
require_once __DIR__ . '/../autoload.php';

// Ici, on appelle un contrôleur pour afficher la page d'accueil
use App\Controllers\HomeController;

// On instancie le contrôleur
$controller = new HomeController();

// On appelle la méthode 'index' de ce contrôleur
$controller->index();

Explication ligne par ligne :

• require_once __DIR__ . '/../autoload.php'; : on inclut un fichier qui va s’occuper de charger automatiquement les classes nécessaires.
• use App\Controllers\HomeController; : on précise qu’on va utiliser le contrôleur de la page d’accueil.
• Ensuite, on le crée et on exécute sa méthode index().

Étape 3 – Le fichier .htaccess pour gérer les URL

Dans le dossier public/, créez un fichier nommé .htaccess.

Ce fichier est lu par le serveur Apache. Il sert ici à rediriger toutes les requêtes vers le fichier index.php, ce qui nous permettra plus tard d’avoir des URL comme site.com/profil sans que ce soit un vrai fichier profil.php.

Voici le contenu du fichier .htaccess pour l’url-rewriting :

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]

Si vous ne mettez pas ce fichier, vos pages ne s’afficheront pas correctement quand vous ajouterez d’autres routes.

Étape 4 – Le système d’autoload : autoload.php

Dans le dossier racine de votre projet, créez le fichier autoload.php.

Son rôle est très important : quand une classe comme App\Controllers\HomeController est appelée, ce fichier va automatiquement charger le bon fichier PHP.

Voici le contenu :

<?php
spl_autoload_register(function ($class) {
    // On remplace le début du namespace par le chemin
    $class = str_replace('App\\', 'app/', $class);

    // On remplace les antislashs par des slashs
    $class = str_replace('\\', '/', $class);

    // On construit le chemin complet du fichier
    $file = __DIR__ . '/' . $class . '.php';

    // Si le fichier existe, on l’inclut
    if (file_exists($file)) {
        require_once $file;
    } else {
        echo "Fichier introuvable : $file";
    }
});

Explication :

• PHP ne sait pas automatiquement où sont les fichiers de vos classes.
• spl_autoload_register() permet de définir une fonction spéciale qui sera appelée automatiquement à chaque fois qu’une classe inconnue est utilisée.
• On transforme le nom de la classe en chemin vers le bon fichier (par exemple : App\Controllers\HomeController devient app/Controllers/HomeController.php).

Étape 5 – Le contrôleur de base : Controller.php

Dans app/Core/, créez un fichier nommé Controller.php.

Ce fichier contiendra la classe mère de tous les contrôleurs. Elle servira à regrouper des fonctions utiles comme render()qui permet d’afficher une vue.

<?php
namespace App\Core;

class Controller
{
    // Méthode pour afficher une vue
    public function render($view, $data = [])
    {
        // On prépare le chemin du fichier vue
        $viewPath = __DIR__ . '/../Views/' . $view . '.php';

        // On transforme chaque clé du tableau $data en variable
        extract($data);

        // Si le fichier existe, on l’inclut
        if (file_exists($viewPath)) {
            require $viewPath;
        } else {
            echo "Vue introuvable : $viewPath";
        }
    }
}

Grâce à cette méthode render, nos futurs contrôleurs pourront très facilement afficher des pages HTML tout en y injectant des données dynamiques.

Étape 6 – Le contrôleur de la page d’accueil : HomeController.php

Dans le dossier app/Controllers/, créez un fichier HomeController.php.

Voici le contenu :

<?php
namespace App\Controllers;

use App\Core\Controller;

class HomeController extends Controller
{
    public function index()
    {
        // Données à transmettre à la vue
        $this->render('home', [
            'titre' => 'Bienvenue sur Créa-code',
            'slogan' => 'Apprenez le développement web gratuitement.'
        ]);
    }
}

Ce contrôleur hérite de notre contrôleur de base, et appelle la vue home.php en lui transmettant deux variables : titre et slogan.

Étape 7 – La vue de la page d’accueil : home.php

Dans le dossier app/Views/, créez le fichier home.php.

Voici son contenu :

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <title><?= $titre ?></title>
</head>
<body>
    <h1><?= $titre ?></h1>
    <p><?= $slogan ?></p>
</body>
</html>

Cette page HTML simple affiche le titre et le slogan que nous avons transmis depuis le contrôleur.

Nous avons déjà mis en place les bases du modèle MVC pour le site code.crea-troyes.fr. Vous avez maintenant un système qui permet de charger un contrôleur et d’afficher une vue proprement. Continuons avec les bonnes pratiques, notamment la sécurisation du dossier app, puis la mise en place des modèles pour préparer le terrain à la base de données.

Pour résumé :

Dans une architecture MVC, le Modèle est la partie qui gère les données. Il communique avec la base de données, récupère ou enregistre des informations, puis les transmet au contrôleur. Le modèle ne s’occupe ni de l’affichage ni de l’interaction avec l’utilisateur : il se concentre uniquement sur la logique métier et la gestion des données.

Le Contrôleur, lui, fait le lien entre l’utilisateur et le système. Il reçoit les actions de l’utilisateur (par exemple, en cliquant sur un bouton ou en ouvrant une page), fait appel au modèle pour obtenir ou modifier des données, puis choisit la Vue à afficher. La Vue est la partie visible pour l’utilisateur : elle présente les données sous forme HTML, souvent accompagnée de CSS et de JavaScript pour rendre l’interface agréable et interactive.

Étape 8 – Sécuriser le dossier app/

Le dossier app/ contient le cœur de votre application. Il contient vos fichiers PHP internes, que personne ne doit pouvoir consulter directement depuis un navigateur. Si quelqu’un tape une URL comme https://votresite.fr/app/Views/home.php, il ne doit jamais voir ce fichier.

Pour cela, on va utiliser une méthode simple : créer un fichier .htaccess dans le dossier app/ qui interdit l’accès depuis le web.

Créez le fichier .htaccess dans app/

Voici le contenu du fichier :

Deny from all

Cette règle indique à Apache de refuser tout accès au dossier, sauf pour le serveur PHP qui l’utilise en interne.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

💡 Vous pouvez faire cela pour tous les dossiers internes de votre projet (comme app/Core, app/Models, etc.) si besoin. Seul le dossier public/ doit être accessible directement depuis le navigateur.

Étape 9 – Préparer le dossier Models/

Même si nous n’allons pas encore connecter notre site à une base de données aujourd’hui, il est important de préparer la partie Modèle du MVC. C’est ici que vous placerez tout ce qui concerne la récupération, la sauvegarde ou la manipulation des données.

Pour l’instant, créons un modèle de base vide, que les autres modèles pourront plus tard étendre.

Créez le fichier app/Models/Model.php

<?php
namespace App\Models;

class Model
{
    // Ce fichier est pour le moment vide
    // Il servira plus tard de base commune pour vos futurs modèles
}

Ce fichier ne fait rien pour le moment, mais il est important d’avoir une structure claire dès le début.

Par la suite, quand vous créerez un modèle UserModel.php, par exemple, vous pourrez écrire :

class UserModel extends Model { ... }

Cela permet à tous vos modèles de partager des fonctionnalités communes (comme la connexion à la base de données, ou des méthodes pour exécuter des requêtes SQL).

Étape 10 – Ajouter une page d’erreur 404 simple

Pour l’instant, si vous demandez une page qui n’existe pas, le site va probablement afficher une erreur PHP. Ce n’est ni beau ni très rassurant pour un visiteur.

Ajoutons une page d’erreur simple que l’on pourra appeler en cas de besoin.

Créez la vue app/Views/error.php

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <title>Page introuvable</title>
</head>
<body>
    <h1>Erreur 404</h1>
    <p>Désolé, la page que vous cherchez n'existe pas.</p>
</body>
</html>

Adapter index.php pour appeler cette page si besoin

Vous pouvez modifier légèrement public/index.php pour vérifier que le contrôleur et la méthode existent bien avant de les exécuter. Ce sera amélioré plus tard avec un vrai système de routage, mais voici une version simple pour commencer :

<?php
require_once __DIR__ . '/../autoload.php';

use App\Controllers\HomeController;

// On vérifie que la classe existe
if (class_exists(HomeController::class)) {
    $controller = new HomeController();

    // On vérifie que la méthode existe
    if (method_exists($controller, 'index')) {
        $controller->index();
    } else {
        require_once __DIR__ . '/../app/Views/error.php';
    }
} else {
    require_once __DIR__ . '/../app/Views/error.php';
}

Étape 11 – Vérifiez que tout fonctionne

À ce stade, vous pouvez lancer votre site en allant sur l’URL correspondant à votre projet local (par exemple : http://localhost/code-crea/public/).

Vous devriez voir :

Bienvenue sur Créa-code
Apprenez le développement web gratuitement.

Si vous modifiez le nom du contrôleur ou de la méthode, vous devez voir la page d’erreur 404 que nous avons prévue.

Étape 12 – Préparer le futur (connexion à la base de données)

Même si ce n’est pas encore pour maintenant, vous pouvez dès maintenant ajouter un fichier config.php à la racine du projet. Il contiendra vos informations de connexion à la base MySQL plus tard.

Créez config.php

<?php
// Informations de connexion à la base de données (à adapter plus tard)
define('DB_HOST', 'localhost');
define('DB_NAME', 'code_crea');
define('DB_USER', 'root');
define('DB_PASS', '');

// Vous pourrez plus tard utiliser ces constantes pour connecter PDO

Cela permet d’éviter d’écrire ces informations dans tous vos fichiers PHP. En centralisant vos paramètres, vous facilitez les modifications futures.

Résumé des bonnes pratiques

Vous avez maintenant une base propre, claire et évolutive. Voici ce que vous avez mis en place aujourd’hui :

• Une architecture MVC qui sépare les responsabilités entre contrôleurs, vues et modèles.
• Un point d’entrée unique (public/index.php) qui lance votre application.
• Un système d’autoload qui charge automatiquement les classes nécessaires.
• Une vue dynamique avec des données injectées depuis le contrôleur.
• Un système d’erreur simple.
• Une protection du dossier app/ pour éviter l’accès direct aux fichiers sensibles.

Vous êtes désormais prêts à construire tout type de page : page de connexion, page de profil, liste des utilisateurs, etc.

Prochainement, nous allons ajouter :

• Un vrai système de routes, pour gérer automatiquement les URLs et appeler les bons contrôleurs.
• Un layout pour le header et le footer
• Une connexion à une base de données MySQL via PDO.
• Le tout premier modèle : les utilisateurs.
• Des formulaires sécurisés, la gestion des sessions, et bien d’autres choses.

Vous venez d’achever un des moments clés du projet code.crea-troyes.fr. L’architecture MVC est un pilier fondamental de nombreux sites web. En l’ayant construite vous-même, sans framework, vous comprenez mieux comment les choses fonctionnent. Cela vous rend plus autonome, plus créatif, et plus confiant pour la suite.

Prenez le temps de relire chaque fichier, de tester des modifications, et de bien comprendre les liens entre eux. Posez-vous des questions : Que se passe-t-il si j’enlève extract($data) ? Et si je change le nom du contrôleur ? Plus vous expérimentez, plus vous progressez.

Créer un système de routes dynamiques

Jusqu’ici, vous appeliez manuellement HomeController@index. Ce n’est pas pratique pour un vrai site. L’objectif maintenant est de faire ceci :

• Lorsqu’un visiteur entre l’URL https://code.crea-troyes.fr/, cela appelle automatiquement HomeController@index.
• Lorsqu’il entre https://code.crea-troyes.fr/user/profile, cela appelle UserController@profile.
• Et ainsi de suite.

Organisation des routes

Nous allons donc lire l’URL, séparer les segments (ex: /user/profile devient ["user", "profile"]) et chercher automatiquement le bon contrôleur et la bonne méthode.

Fichier : public/index.php (mise à jour complète)

Voici le nouveau code de votre point d’entrée :

<?php
require_once __DIR__ . '/../autoload.php';

use App\Controllers\HomeController;

// Récupère l’URL depuis la variable globale $_GET
$url = $_GET['url'] ?? '';
$url = trim($url, '/');
$segments = explode('/', $url);

// Si aucun segment n’est donné, on appelle HomeController@index
$controllerName = !empty($segments[0]) ? ucfirst($segments[0]) . 'Controller' : 'HomeController';
$methodName = $segments[1] ?? 'index';

// Namespace complet
$controllerClass = 'App\\Controllers\\' . $controllerName;

if (class_exists($controllerClass)) {
    $controller = new $controllerClass();

    if (method_exists($controller, $methodName)) {
        // On appelle la méthode avec les paramètres suivants (ex: /user/show/12)
        $params = array_slice($segments, 2);
        call_user_func_array([$controller, $methodName], $params);
    } else {
        require_once __DIR__ . '/../app/Views/error.php';
    }
} else {
    require_once __DIR__ . '/../app/Views/error.php';
}

Explication :

• On découpe l’URL en segments.
• Le premier segment correspond au nom du contrôleur (UserController, HomeController, etc.).
• Le deuxième segment est le nom de la méthode (index, profile, etc.).
• Les autres segments sont passés comme paramètres à la méthode.

Sécuriser le routage PHP via l’URL : analyse et bonnes pratiques

Il est courant d’utiliser un système de routage pour diriger les requêtes vers le bon contrôleur et la bonne méthode en fonction de l’URL demandée. Le script présenté ici permet de récupérer une URL via la méthode GET et d’appeler dynamiquement un contrôleur et une méthode. Cependant, ce genre de mécanisme peut comporter des risques de sécurité s’il n’est pas correctement protégé.

Voici le fonctionnement général du script :

1. Vous récupérez la partie de l’URL dans la variable $_GET['url'].
2. Vous découpez cette URL en segments (par exemple, /user/show/12 devient ['user', 'show', '12']).
3. Vous définissez le contrôleur à appeler, en ajoutant le suffixe Controller.
4. Vous définissez la méthode à exécuter (exemple : show).
5. Vous instanciez la classe correspondante et vous appelez la méthode avec les éventuels paramètres.

Pourquoi ce script n’est pas sécurisé en l’état ?

Votre script fonctionne, mais il comporte plusieurs risques :

• Injection de classes ou méthodes non prévues : un utilisateur malveillant pourrait demander par URL un contrôleur qui n’existe pas, ou pire, un contrôleur sensible.
• Appel de méthodes privées ou non destinées à être accessibles via l’URL.
• Injection de caractères dangereux dans le nom des classes ou méthodes.
• Paramètres passés sans aucune validation aux méthodes, ce qui peut ouvrir la porte à des failles comme les injections SQL, XSS, etc…
• Affichage possible d’erreurs techniques qui pourraient divulguer des informations sensibles.

1. Valider strictement le nom du contrôleur et de la méthode

Avant de tenter d’instancier une classe, vous devez vérifier que le nom de la classe et de la méthode respecte un format strict. Par exemple, le contrôleur doit commencer par une majuscule, finir par Controller, et ne contenir que des lettres et chiffres. La méthode ne doit contenir que des lettres, chiffres ou underscores.

if (!preg_match('/^[A-Z][a-zA-Z0-9]*Controller$/', $controllerName)) {
    require_once __DIR__ . '/../app/Views/error.php';
    exit;
}

if (!preg_match('/^[a-zA-Z0-9_]+$/', $methodName)) {
    require_once __DIR__ . '/../app/Views/error.php';
    exit;
}

Cette validation élimine toute tentative d’injection de code ou d’accès à des classes/méthodes non prévues.

2. Utiliser une liste blanche de contrôleurs et méthodes autorisés

Même avec la validation des noms, il est conseillé de restreindre strictement les contrôleurs et méthodes que l’on souhaite rendre accessibles. Cette liste blanche sert à bloquer toute tentative d’accès à un contrôleur ou une méthode qui ne doit pas être publique.

$allowedControllers = ['HomeController', 'UserController', 'ProductController'];
$allowedMethods = ['index', 'show', 'edit'];

if (!in_array($controllerName, $allowedControllers) || !in_array($methodName, $allowedMethods)) {
    require_once __DIR__ . '/../app/Views/error.php';
    exit;
}

Vous adaptez cette liste selon les classes et méthodes que vous souhaitez exposer.

3. Protéger les paramètres passés aux méthodes

Les paramètres extraits de l’URL (tout ce qui suit /controller/methode/) sont transmis directement à la méthode. Or, ces données peuvent contenir n’importe quoi, et doivent être validées ou nettoyées.

Exemple :

• Si vous attendez un identifiant numérique, vous devez vérifier que le paramètre est bien un entier.
• Si c’est un texte, vous devez échapper les caractères spéciaux avant toute insertion en base ou affichage.

La validation des paramètres doit être réalisée dans les contrôleurs eux-mêmes, dans les méthodes concernées. Vous pouvez utiliser des fonctions comme filter_var(), intval(), htmlspecialchars(), ou d’autres mécanismes adaptés à vos besoins.

4. Gestion des erreurs et affichage

Dans votre script, vous affichez une page d’erreur générique (error.php) quand un contrôleur ou une méthode n’existe pas. C’est très bien. Veillez à ce que cette page n’affiche aucune information sensible comme des traces d’erreurs ou des chemins serveurs.

En production, il faut désactiver display_errors dans la configuration PHP, afin qu’aucune erreur technique ne soit visible par les visiteurs.

5. Résumé du script sécurisé

Voici à quoi peut ressembler votre script final, sécurisé et prêt pour la production :

<?php
 __DIR__ . '/../autoload.php';

$url = $_GET['url'] ?? '';
$url = trim($url, '/');
$segments = explode('/', $url);

$controllerName = !empty($segments[0]) ? ucfirst($segments[0]) . 'Controller' : 'HomeController';
$methodName = $segments[1] ?? 'index';

// Validation des noms
if (!preg_match('/^[A-Z][a-zA-Z0-9]*Controller$/', $controllerName)) {
    require_once __DIR__ . '/../app/Views/error.php';
    exit;
}

if (!preg_match('/^[a-zA-Z0-9_]+$/', $methodName)) {
    require_once __DIR__ . '/../app/Views/error.php';
    exit;
}

// Liste blanche des contrôleurs et méthodes
$allowedControllers = ['HomeController', 'UserController', 'ProductController'];
$allowedMethods = ['index', 'show', 'edit'];

if (!in_array($controllerName, $allowedControllers) || !in_array($methodName, $allowedMethods)) {
    require_once __DIR__ . '/../app/Views/error.php';
    exit;
}

$controllerClass = 'App\\Controllers\\' . $controllerName;

if (class_exists($controllerClass)) {
    $controller = new $controllerClass();

    if (method_exists($controller, $methodName)) {
        $params = array_slice($segments, 2);

        // Note : validez ici les paramètres dans les méthodes appelées !

        call_user_func_array([$controller, $methodName], $params);
    } else {
        require_once __DIR__ . '/../app/Views/error.php';
    }
} else {
    require_once __DIR__ . '/../app/Views/error.php';
}

Le routage dynamique via une URL est puissant mais doit être traité avec beaucoup de précautions. Voici les points clés à retenir pour sécuriser ce type de script :

• Ne jamais faire confiance aux données reçues via $_GET sans validation stricte.
• Valider systématiquement le format des noms des classes et méthodes.
• Limiter l’accès aux contrôleurs et méthodes via une liste blanche.
• Valider ou nettoyer tous les paramètres transmis avant de les utiliser.
• Ne pas divulguer d’informations techniques en cas d’erreur.
• Gérer les erreurs proprement pour ne pas exposer le code ou la structure interne.

Si vous appliquez ces règles, votre script sera robuste et sécurisé, prêt pour un environnement de production.

Connexion à une base de données MySQL avec PDO

Fichier : app/Core/Database.php

Créons une classe Database que tous vos modèles utiliseront pour se connecter à la base de données.

<?php
namespace App\Core;

use PDO;
use PDOException;

class Database
{
    private static $instance = null;
    private $pdo;

    private function __construct()
    {
        try {
            $this->pdo = new PDO(
                'mysql:host=' . DB_HOST . ';dbname=' . DB_NAME . ';charset=utf8',
                DB_USER,
                DB_PASS,
                [
                    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
                    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
                ]
            );
        } catch (PDOException $e) {
            die('Erreur connexion base de données : ' . $e->getMessage());
        }
    }

    public static function getInstance()
    {
        if (self::$instance === null) {
            self::$instance = new Database();
        }
        return self::$instance->pdo;
    }
}

Mettez à jour config.php avec les bonnes informations

<?php
define('DB_HOST', 'localhost');
define('DB_NAME', 'code_crea');
define('DB_USER', 'root');
define('DB_PASS', 'root');

💡 Avec cette configuration, tous vos modèles pourront accéder à la base de données via :

$pdo = \App\Core\Database::getInstance();

La suite demain avec la création d’un système de routage comme pour les frameworks et la création des layouts. Nous continuerons a améliorer notre architecture MVC en PHP !

Alban

Fondateur de l’agence Créa-troyes.
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr