Découverte de la structure d'un projet Symfony

Introduction

Dans l'article précédent, nous avons créé et lancé notre premier projet Symfony. Maintenant que votre environnement est prêt, il est temps de comprendre comment est organisé ce projet et où vous allez travailler au quotidien.

Cette connaissance est essentielle pour naviguer facilement dans votre projet, savoir où placer vos fichiers et préparer vos développements futurs.

Dans cet article, nous allons explorer :

• l'arborescence complète du projet,

• les fichiers clés à connaître,

• le concept MVC (Model-View-Controller),

• les bases de la Programmation Orientée Objet (POO),

• et créer un petit exemple pratique pour mieux visualiser.

1- Arborescence générale du projet

Un projet Symfony peut sembler complexe au début. Maintenant, analysons chaque dossier en détail. Pour simplifier, nous allons faire des comparaisons avec HTML, CSS et PHP, technologies que vous connaissez déjà.

bin/

Rôle : Contient les scripts exécutables pour Symfony.

Utilité : Le script console vous permet de lancer des commandes comme créer une entité ou exécuter des migrations.

Équivalent PHP : Un fichier PHP exécuté depuis le terminal pour automatiser des tâches.

Exemple d'utilisation :

symfony console make:controller

Vous pouvez utiliser symfony console ou php bin/console, ça revient au même.

config/

Rôle : Contient toutes les configurations du projet.

Exemples : Routes, services, packages installés.

Équivalent HTML/CSS : Comme un index.php central ou un fichier style.css, mais pour l'organisation globale du projet.

Fichiers importants :

• routes.yaml : définit vos routes

• services.yaml : configure vos services

• packages/ : configuration des bundles installés

public/

Rôle : Point d'entrée web, contient index.php et les ressources publiques (CSS, JS, images).

Le fichier index.php est le point d'entrée unique de votre application : toutes les requêtes HTTP passent par lui avant d'être dirigées vers le bon contrôleur. C'est le chef d'orchestre qui démarre Symfony.

Équivalent HTML/CSS : Comme le dossier où vous placez vos fichiers HTML et CSS accessibles depuis le navigateur.

src/

Rôle : Contient le code source principal de votre projet. C'est ici que vous allez travailler 90% du temps !

Sous-dossiers importants :

• Controller/ : gère la logique et les routes (comme vos fichiers PHP qui produisent du HTML).

• Entity/ : représente vos données, par exemple un utilisateur ou un article.

• Repository/ : interagit avec la base de données pour récupérer ou modifier les données.

Équivalent PHP : Les Controllers sont vos fichiers PHP dynamiques, Entities vos objets ou tableaux représentant les données, et Repositories vos fonctions pour interagir avec MySQL.

templates/

Rôle : Contient les fichiers Twig pour l'affichage.

Équivalent HTML : Comme vos fichiers .html, mais avec la possibilité d'y insérer du PHP simplifié via Twig.

tests/

Rôle : Contient les tests unitaires et fonctionnels pour vérifier que votre code fonctionne.

Équivalent PHP : Comme écrire un script PHP pour vérifier vos fonctions.

var/

Rôle : Contient cache, logs et fichiers temporaires.

Équivalent PHP : Comme vos dossiers tmp/ ou vos logs manuels.

À savoir : Ce dossier est automatiquement géré par Symfony, vous n'avez pas besoin d'y toucher.

vendor/

Rôle : Contient toutes les dépendances installées via Composer.

Équivalent PHP : Comme inclure un fichier PHP externe avec require ou include, mais géré automatiquement par Composer.

Important : Ne modifiez JAMAIS le contenu de ce dossier ! Tout est géré par Composer.

2- Fichiers clés à connaître

.env - Variables d'environnement

Contient les informations sensibles et la configuration de votre projet :

• Connexion à la base de données

• Mode de l'application (dev/prod)

• Clés API

Exemple de contenu :

APP_ENV=dev
APP_SECRET=

DATABASE_URL="mysql://app:!ChangeMe!@127.0.0.1:3306/app?serverVersion=10.11.2-MariaDB&charset=utf8mb4"

⚠️ IMPORTANT : Ne JAMAIS commiter ce fichier sur Git ! Utilisez .env.local(un fichier à créer) pour vos configurations locales personnelles.

composer.json - Gestionnaire de dépendances

Liste tous les packages (bibliothèques) dont votre projet a besoin.

Pensez-y comme : La liste de courses de votre projet Symfony. Composer va "faire les courses" automatiquement pour vous.

symfony.lock - Verrouillage des versions

Garantit que tous les développeurs de l'équipe utilisent exactement les mêmes versions des packages. Ne touchez jamais à ce fichier manuellement.

Maintenant que nous avons vu la structure des dossiers et les fichiers importants, parlons d'un outil que vous allez utiliser quotidiennement dans vos templates : Twig.

3- Qu'est-ce que Twig ?

Avant de continuer, parlons de Twig. C'est le moteur de templates de Symfony. Pensez à Twig comme du HTML enrichi qui permet d'afficher des variables PHP de manière simple et sécurisée.

Comparaison :

Avant (PHP classique) :

<h1><?php echo $message; ?></h1>

Maintenant (Twig) :

<h1>{{ message }}</h1>

Plus simple, plus lisible, et plus sécurisé ! Twig échappe automatiquement les caractères dangereux pour éviter les failles de sécurité.

4- Comprendre le MVC dans Symfony

Symfony suit le modèle MVC (Model-View-Controller) :

• Model / Entity : représente vos données et votre logique métier.

• View (Twig) : affichage côté utilisateur.

• Controller : reçoit les requêtes, traite la logique et renvoie une réponse.

Schéma du flux :

┌─────────────┐
│ Utilisateur │ Tape une URL dans le navigateur
└──────┬──────┘
       ↓
┌──────────────┐
│    Router    │ Trouve la route correspondante
└──────┬───────┘
       ↓
┌──────────────┐
│  Controller  │ Traite la demande
└──────┬───────┘
       ↓
┌──────────────┐
│ Model/Entity │ Récupère les données si nécessaire
└──────┬───────┘
       ↓
┌──────────────┐
│ View (Twig)  │ Génère le HTML
└──────┬───────┘
       ↓
┌──────────────┐
│   Réponse    │ Page affichée au visiteur
└──────────────┘

Exemple concret :

1. L'utilisateur visite /bienvenue

2. Le router appelle le WelcomeController

3. Le contrôleur récupère des données (si nécessaire)

4. Le contrôleur envoie les données au template Twig welcome/index.html.twig

5. Twig génère le HTML final

6. L'utilisateur voit la page

5- Comprendre la Programmation Orientée Objet (POO)

Avant de créer notre premier contrôleur, clarifions quelques concepts de la Programmation Orientée Objet car Symfony utilise intensivement la POO.

Qu'est-ce qu'une classe ?

Une classe est comme un modèle ou un plan qui définit la structure et le comportement d'objets.

Comparaison concrète : Imaginez une classe comme le plan d'une maison :

• Le plan (classe) définit les pièces, les portes, etc.

• Chaque maison construite à partir de ce plan est un objet (une instance de la classe)

Comparaison PHP procédural vs POO :

Avant (PHP procédural) :

// accueil.php
function afficherBienvenue() {
    echo "Bienvenue !";
}

function afficherAuRevoir() {
    echo "Au revoir !";
}

afficherBienvenue();

Maintenant (POO avec Symfony) :

class WelcomeController 
{
    public function bienvenue() {
        return "Bienvenue !";
    }

    public function auRevoir() {
        return "Au revoir !";
    }
}

Avantages : Les fonctions (appelées méthodes dans une classe) sont regroupées logiquement. C'est plus organisé et réutilisable.

Note importante : Dans Symfony, nos classes de contrôleurs vont hériter d'une classe parente pour avoir des super-pouvoirs. Nous en parlerons plus tard.

Vous avez maintenant une vision claire de la structure d’un projet Symfony. Vous savez à quoi sert chaque dossier, comment le framework applique le modèle MVC et pourquoi la programmation orientée objet est si importante dans Symfony.

Dans le prochain article, nous passerons à la pratique : nous créerons notre premier contrôleur Symfony, découvrirons les namespaces, les routes et la liaison avec Twig pour afficher nos premières pages.

À très bientôt pour continuer cette aventure Symfony !