4.3Symfony: components, Twig, Doctrine
The essentials in 30 seconds
- Symfony = reusable components: routing, forms, security, console — usable together or separately, even outside Symfony.
- Twig + Doctrine:
{{ }}, {% for %}templates escaped by default, and the database handled as object entities with automatic prepared statements. - Riad's reflex: same concepts as Laravel (MVC, ORM, templates) — mastering one makes the other easier; choose according to project and market.
Running case — Riad discovers Symfony at a client
An enterprise client of Riad, in Constantine, requires Symfony for its back office: rigour, proven components, traceability. Riad finds his Laravel bearings under different names — routes to controllers, Twig templates instead of Blade, Doctrine entities instead of Eloquent models — and even picks a Symfony component (the console) for an old script. Third milestone of the thread: two frameworks, same ideas, pro adaptability.
Continues the 4.1-4.2 case — Riad becomes Laravel/Symfony bilingual.
1. A component architecture
Symfony is the OTHER major PHP framework, favoured in ENTERPRISE and on large projects: rigorous, modular, built for complexity. Its trademark: independent COMPONENTS (routing, forms, security, console, HTTP, validation, dependency injection…), each tested separately and reusable outside Symfony via Composer. Many projects — including Laravel — use Symfony components under the hood: it is a pillar of the ecosystem. Adopt it as a complete framework or by picking individual building blocks.
2. Twig & Doctrine
Twig is the template engine: {{ variable }}, {% for %}, {% if %}, inheritance — with automatic escaping (anti-XSS), appreciated well beyond Symfony. Doctrine is the associated ORM: you handle entities (objects) instead of SQL, automatic prepared statements, relations, migrations. Design nuance: Doctrine follows the "Data Mapper" pattern (entities separated from persistence) while Eloquent follows "Active Record" (models persist themselves) — two excellent philosophies.
Laravel (approachable, productive) vs Symfony (rigorous, enterprise): two mature, pro choices, SAME concepts (MVC, routing, ORM, templates, security). Riad picks according to context — starting fast, enterprise constraint, local market — without anxiety: the essentials transfer.
🔎 Concrete example — 🔎 Concrete example — Symfony catalogue: controller, Twig, Doctrine
Riad's three moves on the Symfony side:
Controller → route /produits, renders produits/index.html.twig
Twig → {% for p in produits %}{{ p.nom }} {% endfor %}
Doctrine → $repo->findBy(['categorie' => $cat]) // entities, no SQLReading: same roles as Laravel, Symfony vocabulary.
Lesson: whoever knows one reads the other without panic.
Section vocabulary
- Symfony
- The other major PHP framework (with Laravel), known as rigorous, modular, favoured in enterprise and on large projects.
Simple example: Riad's enterprise back-office client requires it for its rigour.
What it is not: a micro-script with no structure or tests.
Reflex: demanding large project? evaluate Symfony first.
- Symfony components
- Independent building blocks (routing, forms, security, console…) usable separately, even outside Symfony; used under the hood by many, including Laravel.
Simple example: Riad installs just the console component into an old script.
What it is not: a monolithic framework to take or leave.
Reflex: pick via Composer when the whole framework is too much.
- Twig (templates)
- Symfony template engine: {{ }}, {% for %}, {% if %}, inheritance — automatic anti-XSS escaping, appreciated beyond Symfony.
Simple example: Riad loops {% for p in produits %} with escaped display.
What it is not: PHP logic piled into the template.
Reflex: templates dedicated to display, logic elsewhere.
- Doctrine (ORM)
- ORM associated with Symfony: object entities instead of SQL, automatic prepared statements, relations, migrations; Data Mapper approach.
Simple example: Riad reads $repo->findBy(['categorie' => $cat]) without writing the SELECT.
What it is not: hand-concatenated SQL inside the controller.
Reflex: entities for business, repository for queries.
- Laravel vs Symfony
- Two excellent mature frameworks: Laravel approachable/productive; Symfony rigorous/modular/enterprise. Same transferable concepts.
Simple example: Riad moves from one to the other by translating Blade↔Twig, Eloquent↔Doctrine.
What it is not: an anxious once-and-for-all choice "for life".
Reflex: choose per project, team and local market.
In practice — In practice — Discover Symfony and its components
- Understand the philosophy: rigorous, modular, built of REUSABLE components, favoured in enterprise.
- Spot Twig ({{ }}, {% for %}, automatic escaping) and Doctrine (entities instead of SQL, relations, migrations).
- Note the ORM difference: Doctrine (Data Mapper) vs Eloquent (Active Record).
- Place the Laravel/Symfony choice (productivity vs rigour/enterprise): the concepts transfer.
Ready-to-say script — reassure about the Symfony choice (30 s)
"This is Riad: Symfony gives us proven components, safe Twig templates and Doctrine for our entities — the rigour this enterprise client expects. And our Laravel knowledge transfers: same concepts, different vocabulary."
Say it in a client meeting; show the Blade/Twig, Eloquent/Doctrine mapping.
Copy-paste template — Symfony controller + Twig + Doctrine (tested code)
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 %}
Enterprise project
Full Symfony: rigour, security/forms components, traceability — like Riad's client.
Legacy PHP project
Pick one component (console, validation, routing) via Composer without migrating everything.
Laravel team
Translate: Blade→Twig, Eloquent→Doctrine — the ramp-up is fast.
Choice to settle
Fast, independent start: Laravel; big enterprise system: Symfony.
.env, never hardcoded. Teaching content, examples with fictitious data.✓ Best practices
- See Symfony as reusable components.
- Recognize known concepts under different names.
- Choose per project and market, with no dogma.
✗ Common pitfalls
- Pitting Laravel and Symfony against each other as camps.
- Putting logic in Twig.
- Agonizing over the "right" final choice.
Key takeaways
- SYMFONY = other major PHP framework: RIGOROUS, MODULAR, ENTERPRISE. Reusable components (even used by Laravel).
- TWIG: {{ }}, {% for %}, automatic escaping. DOCTRINE: entities instead of SQL, relations, migrations.
- Doctrine (Data Mapper) vs Eloquent (Active Record): two excellent approaches.
- SAME CONCEPTS (MVC, ORM, templates, routing, security) — transferable. Mastering one makes the other easier.
48h challenge — apply it tomorrow
Render 1 list via Twig + Doctrine (controller → findBy → {% for %} loop) and install 1 standalone component via Composer.
- I can name components, Twig, Doctrine.
- I can explain Data Mapper vs Active Record.
- I have 1 Symfony page rendering entities.
Frequently asked questions
Laravel or Symfony: which one to learn — does it matter that much?
Both are excellent and mature; what matters most is the transferable CONCEPTS (MVC, ORM, templates, routing, security). Laravel: approachable, productive, friendly — often recommended to start. Symfony: rigorous, modular, enterprise/large projects. Choose per project, team and local market — and know how to move from one to the other: it is feasible precisely because the ideas are the same.
Why is Symfony a set of "components" — and why does it matter?
Because each component (routing, forms, security, console…) is standalone, tested separately and reusable outside Symfony via Composer — modularity, flexibility (complete framework or hand-picked blocks) and a pillar role in the ecosystem (other projects use them). It is good architecture at framework scale, and a toolbox for any PHP project.
What is Symfony's major characteristic?