4.3Symfony : composants, Twig, Doctrine
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.
🔎 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
- Comprenez la philosophie : rigoureux, modulaire, en COMPOSANTS réutilisables, prisé en entreprise.
- Repérez Twig ({{ }}, {% for %}, échappement auto) et Doctrine (entités au lieu de SQL, relations, migrations).
- Notez la différence d'ORM : Doctrine (Data Mapper) vs Eloquent (Active Record).
- Situez le choix Laravel/Symfony (productivité vs rigueur/entreprise) : les concepts se transfèrent.
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.
.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.
- Je peux citer composants, Twig, Doctrine.
- Je sais expliquer Data Mapper vs Active Record.
- J'ai 1 page Symfony qui affiche des entités.
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.
Quelle est la caractéristique majeure de Symfony ?