Ce guide pratique explique comment maîtriser les migrations de base de données avec Symfony 7 et Doctrine. Il couvre l'installation d'un projet Symfony, la création d'entités, la génération et l'application des migrations, ainsi que leur réversion. L'article détaille aussi la personnalisation des migrations (méthodes preUp, postUp, preDown, postDown, gestion des transactions, etc.), l'évolution des propriétés d'entités, et propose une solution pour éviter l'erreur récurrente de création du schéma public avec PostgreSQL. Un template personnalisé pour les migrations et un listener Doctrine sont présentés pour optimiser le workflow. Enfin, une cheatsheet récapitule les commandes utiles pour gérer les migrations efficacement. Idéal pour les développeurs souhaitant approfondir la gestion des schémas de base de données dans Symfony.
L’article aborde les pièges de performance dans Doctrine ORM, notamment la différence entre les stratégies de chargement Lazy, Eager et Extra-Lazy pour les associations entre entités. Par défaut, Doctrine utilise le Lazy Loading, qui peut entraîner le problème classique du N+1 : une requête initiale pour récupérer les articles, suivie d’une requête supplémentaire pour chaque article afin de charger ses commentaires, ce qui dégrade fortement les performances. L’exemple donné montre comment une simple boucle pour afficher le nombre de commentaires par article peut générer 1 + N requêtes (N étant le nombre d’articles), et charger inutilement toutes les données des commentaires en mémoire. L’article souligne l’importance de choisir la bonne stratégie de chargement pour éviter ces écueils.
Symfony, Doctrine et les triggers SQL sont souvent en tension : les triggers offrent une robustesse et une atomicité inégalées pour des logiques critiques (audit, validation, compteurs), mais leur gestion dans un projet Symfony reste complexe, car leur code SQL est souvent perdu dans des migrations ou invisible pour les développeurs. Le Trigger Mapping Bundle propose une solution élégante en permettant de déclarer les triggers directement dans les entités via des attributs PHP, les rendant ainsi visibles, versionnables et gérables comme le reste du code. Le bundle offre des commandes pour intégrer, créer, valider et mettre à jour les triggers, tout en facilitant la transition depuis un projet existant. L’objectif ? Réconcilier la puissance des triggers SQL avec la philosophie de Symfony et Doctrine, en choisissant le bon outil selon le besoin : trigger pour l’intégrité des données, listener Doctrine pour la logique applicative. Une approche qui réduit la dette technique et améliore la maintenabilité.
L’article explique la différence fondamentale entre les DTO (Data Transfer Object) et les Entities dans Symfony, deux concepts clés pour structurer proprement une application. Les Entities représentent les objets métiers persistés en base de données, liés à Doctrine et souvent chargés de logique complexe, tandis que les DTO sont des objets légers, dédiés au transfert de données entre les couches (API, formulaires, services), sans logique métier ni persistance. Utiliser des DTO permet de découpler la validation, la sérialisation et la manipulation des données des Entities, améliorant ainsi la maintenabilité, la sécurité (en évitant d’exposer directement les Entities) et la clarté du code. L’auteur souligne que les DTO sont particulièrement utiles pour gérer les entrées/sorties des contrôleurs ou des services externes, tandis que les Entities restent le cœur du modèle de données. En résumé, bien distinguer les deux optimise l’architecture et réduit les risques d’incohérences ou de fuites de données sensibles.
L’article explique comment moderniser un système de logging dans Symfony en remplaçant les déclencheurs (triggers) traditionnels par les événements Doctrine, une approche plus flexible et maintenable. L’auteure, Jinal Solanki, détaille les limites des triggers (dépendance à la base de données, manque de souplesse) et propose une solution basée sur les listeners Doctrine pour intercepter les opérations CRUD (Create, Read, Update, Delete) directement dans le code PHP. Cette méthode permet de centraliser la logique de logging, de faciliter les tests unitaires et d’éviter les effets de bord liés aux triggers SQL. Elle illustre la mise en œuvre avec des exemples concrets : création d’un EventSubscriber pour écouter les événements prePersist, preUpdate et preRemove, puis enregistrement des changements dans une table dédiée. L’avantage principal est une meilleure intégration avec le code métier, une maintenance simplifiée et une indépendance vis-à-vis du SGBD. Une solution idéale pour rendre le logging évolutif et cohérent dans une architecture Symfony.
L'article aborde un problème courant mais critique dans les projets Symfony utilisant Doctrine et le Symfony Serializer. L'auteur décrit une expérience de débogage où une erreur de mémoire épuisée a été causée par l'utilisation négligente du serializer par défaut de Symfony, qui utilise les métadonnées de Doctrine, entraînant une consommation excessive de mémoire. Le problème est survenu lors de la sérialisation de grandes quantités de données dans une entité contenant de grands champs JSON. La solution proposée consiste à créer un adaptateur de serializer léger qui évite complètement les métadonnées de Doctrine. L'article souligne l'importance d'utiliser des serializers adaptés pour les données internes de débogage ou de sauvegarde et met en garde contre l'utilisation du serializer par défaut pour les entités avec de grandes ou des données imbriquées, afin de rester en contrôle de l'utilisation de la mémoire.
L'article explique comment implémenter le design pattern Strategy dans Symfony 7 pour gérer des comportements différents sous certaines conditions sans utiliser de multiples instructions if. Ce modèle permet de créer des stratégies distinctes et testables individuellement, rendant le code plus élégant et professionnel. L'article décrit la structure du modèle, composée d'une classe de contexte, de classes de stratégie individuelles et de classes auxiliaires. Trois exemples concrets sont fournis : une règle métier, des opérations avec API Platform, et une recherche intelligente avec Doctrine. L'utilisation du pattern Strategy dans Symfony 7 est présentée comme une solution efficace pour centraliser et simplifier la gestion des comportements variés dans une application.
L'auteur utilise une histoire pour rappeler que les migrations Doctrine sont à privilégier, même et surtout pour les insertions manuelles.
L'auteur donne 3 raisons pour lesquelles l'appel à flush() dans les repositories est une mauvaise idée, notamment vis à vis du DDD. Il explique ce qu'il fait à la place.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Pour résumer, dans Doctrine, plutôt que de donner le type "string" à un uuid, donner le type UuidInterface... ça évitera de gros problèmes de performance
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre, sauf que ça concerne PHPUnit, Doctrine, Symfony et Laravel
Un bon exemple de séparation d'utilisation de DTO pour la création d'entités valides. L'auteur montre aussi comment créer une contrainte d'unicité d'un champ Doctrine dans un DTO
Tout est dans le titre