Quiz 2 — Cœur & Doctrine

Le front controller public/index.php (seul dossier exposé au web).

Une Request en entrée, une Response en sortie.

Exécuter des tâches après l’envoi de la réponse (logs lourds, e-mails) sans faire attendre le client.

Par un attribut #[Route(...)] (plus une annotation dans un commentaire).

Un changement de chemin casserait les liens ; on génère par nom de route (path()/generateUrl()).

Il désérialise + valide le corps JSON dans un DTO ; échec → 422 automatique.

Dans des services ; le contrôleur reste fin (lire, déléguer, répondre).

L’injection automatique des dépendances par leur type (aucune config dans le cas courant).

Pour le découplage et la testabilité (changer d’implémentation ou injecter un double sans modifier le code).

Non : c’est un singleton (une instance partagée). D’où l’importance de services sans état.

Avec #[AutowireIterator('tag')] (ou un #[AutowireLocator] pour un chargement paresseux par clé).

« Il s’est passé X » de « réagir à X ». Synchrone ; pour du différé, Messenger.

Data Mapper : l’entité est pure, l’EntityManager persiste (vs Active Record).

persist() planifie ; flush() exécute les opérations en attente (dans une transaction).

Le ManyToOne (porte la FK, inversedBy). L’autre est inverse (mappedBy).

Doctrine ne persiste que d’après le côté propriétaire ; les helpers addX/removeX synchronisent les deux.

Migrations pour le schéma, fixtures pour les données de démo/test.

1 requête + N requêtes sur une relation paresseuse ; corrigé par fetch join (join + addSelect).

Toujours des paramètres nommés + setParameter(), jamais de concaténation.

À éviter : ça se produit pendant la transaction. On dispatche un événement de domaine après flush (ou Messenger).