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
Tout est dans le titre
Tout est dans le titre