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
Tout est dans le titre
Entre autres choses, ça permet de résoudre l'erreur quand on lance "doctrine:schema:validate"
Tout est dans le titre