4.3 · Symfony : composants, Twig, Doctrine

Niveau 4 · Frameworks & API

4.3Symfony : composants, Twig, Doctrine

Objectif : Connaître Symfony (composants, Twig, Doctrine), sa philosophie (rigueur, modularité, entreprise) et sa complémentarité avec Laravel — pour rester adaptable.
Temps estimé : 12 min · lecture autonome · Si vous n'avez que 5 min : lisez « L'essentiel en 30s » + le schéma.

L'essentiel en 30 secondes

  • Symfony = composants réutilisables : routage, formulaires, sécurité, console — utilisables ensemble ou séparément, même hors Symfony.
  • Twig + Doctrine : templates {{ }}, {% for %} échappés par défaut, et base manipulée en entités objets avec requêtes préparées auto.
  • Réflexe de Riad : mêmes concepts que Laravel (MVC, ORM, templates) — maîtriser l'un facilite l'autre, choisir selon projet et marché.

Mini-cas filé — Riad découvre Symfony chez un client

Un client entreprise de Riad, à Constantine, impose Symfony pour son back-office : rigueur, composants éprouvés, traçabilité. Riad retrouve ses repères de Laravel sous d'autres noms — routes vers contrôleurs, templates Twig au lieu de Blade, entités Doctrine au lieu de modèles Eloquent — et pioche même un composant Symfony (la console) pour un vieux script. Troisième jalon du fil rouge : deux frameworks, mêmes idées, adaptabilité pro.

Suite du cas 4.1-4.2 — Riad devient bilingue Laravel/Symfony.

1. Une architecture en composants

Symfony est l'AUTRE grand framework PHP, prisé en ENTREPRISE et sur les gros projets : rigoureux, modulaire, taillé pour la complexité. Sa marque : des COMPOSANTS indépendants (routage, formulaires, sécurité, console, HTTP, validation, injection de dépendances…), chacun testé séparément et réutilisable hors Symfony via Composer. Beaucoup de projets — y compris Laravel — utilisent des composants Symfony sous le capot : c'est un pilier de l'écosystème. On l'adopte comme framework complet ou en piochant des briques.

2. Twig & Doctrine

Twig est le moteur de templates : {{ variable }}, {% for %}, {% if %}, héritage — avec échappement automatique (anti-XSS), apprécié bien au-delà de Symfony. Doctrine est l'ORM associé : on manipule des entités (objets) au lieu de SQL, préparées auto, relations, migrations. Nuance de conception : Doctrine suit le pattern « Data Mapper » (entités séparées de la persistance) quand Eloquent suit « Active Record » (les modèles se persistent eux-mêmes) — deux excellentes philosophies.

Laravel (accessible, productif) vs Symfony (rigoureux, entreprise) : deux choix matures et pros, MÊMES concepts (MVC, routage, ORM, templates, sécurité). Riad choisit selon le contexte — démarrer vite, contrainte entreprise, marché local — sans angoisse : l'essentiel se transfère.

Erreur d'interprétation fréquente : « Laravel et Symfony sont ennemis, il faut choisir son camp ». Non. Ce sont deux implémentations matures des mêmes idées (MVC, ORM, templates, routage, sécurité), liées techniquement (Laravel utilise des composants Symfony). Les opposer fait rater l'essentiel : les concepts transférables. Le bon réflexe est bilingue — comprendre les deux philosophies et choisir selon le projet, pas selon la tribu.
Symfony : composants + duo Twig/Doctrine Briques indépendantes, mêmes concepts ComposantsRoutage, formulaires, sécurité, console+TwigTemplates sûrs, héritage+DoctrineEntités objets, relations, migrations Framework complet ou briques piochées via Composer.
Briques indépendantes, mêmes concepts
Version texte du schéma (SEO / lecteurs d'écran / traduction) : 1) Riad voit Symfony comme un jeu de composants indépendants, réutilisables même hors framework. 2) Twig affiche avec échappement automatique et héritage. 3) Doctrine manipule des entités objets avec préparées auto et migrations. Leçon : mêmes concepts que Laravel sous d'autres noms — l'adaptabilité plutôt que le camp.

🔎 Exemple concret — 🔎 Exemple concret — Catalogue Symfony : contrôleur, Twig, Doctrine

Les trois gestes de Riad côté Symfony :

Contrôleur → route /produits, rend produits/index.html.twig
Twig → {% for p in produits %}
  • {{ p.nom }}
  • {% endfor %} Doctrine → $repo->findBy(['categorie' => $cat]) // entités, pas de SQL

    Lecture : mêmes rôles que Laravel, vocabulaire Symfony.

    Leçon : qui connaît l'un lit l'autre sans panique.

    Vocabulaire de la section

    Symfony
    L'autre grand framework PHP (avec Laravel), réputé rigoureux, modulaire, prisé en entreprise et sur les gros projets.

    Exemple simple : Le back-office entreprise de Riad l'impose pour sa rigueur.

    Ce que ce n'est pas : un micro-script sans structure ni tests.

    Réflexe : gros projet exigeant ? évaluer Symfony en premier.

    Composants Symfony
    Briques indépendantes (routage, formulaires, sécurité, console…) utilisables séparément, même hors Symfony ; utilisées sous le capot par beaucoup, dont Laravel.

    Exemple simple : Riad installe juste le composant console dans un vieux script.

    Ce que ce n'est pas : un framework monolithique à prendre ou à laisser.

    Réflexe : piocher via Composer quand tout le framework est trop.

    Twig (templates)
    Moteur de templates Symfony : {{ }}, {% for %}, {% if %}, héritage — échappement automatique anti-XSS, apprécié au-delà de Symfony.

    Exemple simple : Riad boucle {% for p in produits %} avec affichage échappé.

    Ce que ce n'est pas : du PHP logique entassé dans le template.

    Réflexe : templates dédiés à l'affichage, logique ailleurs.

    Doctrine (ORM)
    ORM associé à Symfony : entités objets au lieu de SQL, préparées auto, relations, migrations ; approche Data Mapper.

    Exemple simple : Riad lit $repo->findBy(['categorie' => $cat]) sans écrire le SELECT.

    Ce que ce n'est pas : du SQL concaténé à la main dans le contrôleur.

    Réflexe : entités pour le métier, dépôt pour les requêtes.

    Laravel vs Symfony
    Deux excellents frameworks matures : Laravel accessible/productif ; Symfony rigoureux/modulaire/entreprise. Mêmes concepts transférables.

    Exemple simple : Riad passe de l'un à l'autre en traduisant Blade↔Twig, Eloquent↔Doctrine.

    Ce que ce n'est pas : un choix angoissé et définitif « pour la vie ».

    Réflexe : choisir selon projet, équipe et marché local.

    En pratique — En pratique — Découvrir Symfony et ses composants

    1. Comprenez la philosophie : rigoureux, modulaire, en COMPOSANTS réutilisables, prisé en entreprise.
    2. Repérez Twig ({{ }}, {% for %}, échappement auto) et Doctrine (entités au lieu de SQL, relations, migrations).
    3. Notez la différence d'ORM : Doctrine (Data Mapper) vs Eloquent (Active Record).
    4. Situez le choix Laravel/Symfony (productivité vs rigueur/entreprise) : les concepts se transfèrent.
    Vous connaissez Symfony (composants, Twig, Doctrine) et sa complémentarité avec Laravel — adaptable sur les deux écosystèmes.

    Script prêt à dire — rassurer sur le choix Symfony (30 s)

    « C'est Riad : Symfony nous donne des composants éprouvés, des templates Twig sûrs et Doctrine pour nos entités — la rigueur qu'attend ce client entreprise. Et nos acquis Laravel se transfèrent : mêmes concepts, autre vocabulaire. »

    À dire en réunion client ; montrez la correspondance Blade/Twig, Eloquent/Doctrine.

    Modèle copier-coller — contrôleur Symfony + Twig + Doctrine (code testé)

    findBy(['categorie' => 'informatique']);
            return $this->render('produits/index.html.twig', ['produits' => $produits]);
        }
    }
    
    // templates/produits/index.html.twig
    // {% extends 'base.html.twig' %}
    // {% block body %}{% for p in produits %}
  • {{ p.nom }} — {{ p.prix }} DA
  • {% endfor %}{% endblock %}

    Projet entreprise

    Symfony complet : rigueur, composants sécurité/formulaires, traçabilité — comme le client de Riad.

    Vieux projet PHP

    Piochez un composant (console, validation, routage) via Composer sans tout migrer.

    Équipe Laravel

    Traduisez : Blade→Twig, Eloquent→Doctrine — la montée en charge est rapide.

    Choix à trancher

    Démarrage rapide et indépendant : Laravel ; gros système entreprise : Symfony.

    Prudence : La rigueur n'immunise pas : validez les formulaires (composant Validator), gardez Twig échappé par défaut et les secrets en .env, jamais en dur. Contenu pédagogique, exemples avec données fictives.

    ✓ Bonnes pratiques

    • Voir Symfony comme composants réutilisables.
    • Retrouver les concepts connus sous d'autres noms.
    • Choisir selon projet et marché, sans dogme.

    ✗ Pièges fréquents

    • Opposer Laravel et Symfony en camps.
    • Mettre de la logique dans Twig.
    • S'angoisser sur le « bon choix » définitif.

    Points clés à retenir

    • SYMFONY = autre grand framework PHP : RIGOUREUX, MODULAIRE, ENTREPRISE. Composants réutilisables (même par Laravel).
    • TWIG : {{ }}, {% for %}, échappement auto. DOCTRINE : entités au lieu de SQL, relations, migrations.
    • Doctrine (Data Mapper) vs Eloquent (Active Record) : deux approches excellentes.
    • MÊMES CONCEPTS (MVC, ORM, templates, routage, sécurité) — transférables. Maîtriser l'un facilite l'autre.

    Défi 48h — appliquez demain

    Affichez 1 liste via Twig + Doctrine (contrôleur → findBy → boucle {% for %}) et installez 1 composant seul via Composer.

    Checklist sortie de section
    • Je peux citer composants, Twig, Doctrine.
    • Je sais expliquer Data Mapper vs Active Record.
    • J'ai 1 page Symfony qui affiche des entités.
    Auto-évaluation 1-5 : mes templates sont-ils sans logique ?puis-je passer d'Eloquent à Doctrine sans panique ?

    Questions fréquentes

    Laravel ou Symfony : lequel apprendre — est-ce si important ?

    Les deux sont excellents et matures ; ce qui compte le plus, ce sont les CONCEPTS transférables (MVC, ORM, templates, routage, sécurité). Laravel : accessible, productif, convivial — souvent conseillé pour débuter. Symfony : rigoureux, modulaire, entreprise/grands projets. Choisissez selon projet, équipe et marché local — et sachez passer de l'un à l'autre : c'est faisable justement parce que les idées sont les mêmes.

    Pourquoi Symfony est-il un ensemble de « composants » — et pourquoi c'est important ?

    Parce que chaque composant (routage, formulaires, sécurité, console…) est autonome, testé séparément et réutilisable hors Symfony via Composer — modularité, flexibilité (framework complet ou briques piochées) et rôle de pilier de l'écosystème (d'autres projets les utilisent). C'est une bonne architecture à l'échelle du framework, et une boîte à outils pour tout projet PHP.

    Vérifiez votre compréhension

    Quelle est la caractéristique majeure de Symfony ?

    Ressources supplémentaires (optionnel, pour aller plus loin)

    Examen du niveau 4Questions inédites et durcies pour valider vos acquis