Twig 3.24.0, sorti avec Symfony 7.4, introduit des fonctionnalités avancées pour simplifier la création de composants UI réutilisables, répondant aux besoins des systèmes de design modernes et des frameworks comme Tailwind. Parmi les nouveautés, la fonction html_attr, la stratégie d'échappement html_attr_relaxed et les opérateurs null-safe améliorent la gestion des attributs HTML et des données dynamiques, réduisant ainsi la complexité des templates.
L'article explique comment abandonner les tableaux non structurés pour des DTOs strictement typés et validés, combinés à des attributs PHP 8.x et à Symfony 7.4's #[MapRequestPayload], afin de transmettre des données propres et validées directement aux templates Twig. Cela renforce la robustesse des applications tout en maintenant une bonne expérience de développement.
Pour utiliser ces fonctionnalités, il est nécessaire d'installer les packages twig/html-extra, symfony/serializer et symfony/validator, et de vérifier que Twig 3.24.0 ou supérieur est bien installé. L'article détaille également la configuration requise et présente un exemple concret de création d'un composant Button avec des DTOs stricts.
L’article explique comment optimiser la gestion de gros fichiers JSON dans Symfony pour éviter les problèmes de mémoire, notamment l’OOM killer. L’idée principale repose sur l’utilisation du composant natif symfony/json-streamer de Symfony 7.4, qui permet de parser les données en flux continu plutôt que de charger l’intégralité du fichier en mémoire. Cette approche réduit drastiquement l’empreinte mémoire, évitant les pièges des méthodes traditionnelles comme json_decode() ou le Serializer, qui dupliquent les données en mémoire.
L’auteur détaille les mécanismes sous-jacents, comme le fonctionnement en DOM des méthodes classiques, qui consomment jusqu’à cinq fois plus de RAM que la taille du fichier initial. À l’inverse, le streaming lit les données octet par octet et ne conserve en mémoire que les éléments actuellement traités, grâce à des DTOs (Data Transfer Objects) typés et à l’attribut #[JsonStreamable]. Cette méthode est particulièrement adaptée aux fichiers de plusieurs gigaoctets ou aux webhooks massifs.
Pour implémenter cette solution, l’article recommande d’installer trois composants Symfony (json-streamer, type-info et object-mapper) et d’exploiter leur intégration native. L’architecture repose sur des Generators PHP, qui libèrent automatiquement la mémoire après traitement de chaque objet, garantissant une consommation constante et minimale.
L’étude du codebase d’etcd, un magasin clé-valeur distribué écrit en Go, a inspiré l’auteur à repenser ses pratiques en PHP. Il met en avant des principes d’architecture logicielle applicables quel que soit le langage, comme la définition stricte des contrats d’API via des DTO typés pour éviter les ambiguïtés et les erreurs en production.
L’auteur souligne également l’importance de la séparation des responsabilités, où chaque service ou classe ne doit accomplir qu’une seule tâche, évitant ainsi les contrôleurs monolithiques difficiles à maintenir. Enfin, il compare les intercepteurs d’etcd aux écouteurs d’événements et au système de messages de Symfony, montrant comment une composition modulaire améliore la lisibilité et la maintenabilité du code.
Cet article explique comment implémenter le pattern CQRS (Command Query Responsibility Segregation) avec Symfony Messenger pour structurer et simplifier le code des applications Symfony. Le CQRS sépare les opérations d'écriture (Commands) et de lecture (Queries), permettant une meilleure organisation, une séparation claire des responsabilités et une validation des données avant la logique métier. L'article détaille les étapes pour créer une application de gestion de bibliothèque, incluant la création d'une entité Book, d'un DTO, la configuration de Symfony Messenger, et l'implémentation des Commands et Queries avec leurs contrôleurs respectifs. Un prérequis est la connaissance de Symfony Messenger.
Florent Destremau discute de l'utilisation des DTO (Data Transfer Objects) dans les formulaires, soulignant que leur utilisation est souvent présentée comme une évidence sans considérer le contexte et le coût de maintenance. Il illustre cela avec un exemple simple où l'ajout d'un DTO et d'un service de mapping pour une entité basique crée une sur-complexité et une duplication de code. Il argue que pour des opérations CRUD simples, les DTO n'apportent que peu de valeur et recommande plutôt d'écrire des tests pour protéger le code. Il montre comment déplacer les contraintes de validation sur l'entité et utiliser du typage strict peut simplifier le code tout en maintenant une bonne robustesse. Il conclut que cette approche résulte en un couplage plus souple et une couverture de test accrue, malgré une perception initiale de moins de rigueur.
Cet article de Sebastian Bergmann explique les différences entre les Data Transfer Objects (DTOs) et les Value Objects, et pourquoi l'immutabilité facilite les tests. Les DTOs, motivés techniquement, servent à transférer des données entre couches ou systèmes, tandis que les Value Objects, motivés par le domaine, représentent des concepts stables du domaine. L'immutabilité réduit la charge cognitive en test, car elle garantit que l'état des objets ne change pas. Les Value Objects, étant immuables, n'ont pas besoin de test doubles, contrairement aux DTOs qui peuvent en nécessiter si ils contiennent de la logique. L'utilisation d'objets immuables simplifie les tests en évitant les effets de bord indirects.
Ce billet explique comment tirer pleinement parti du composant symfony/object-mapper, bien au-delà d'une simple hydratation d'objets à partir de tableaux. L'auteur montre que cet outil, basé sur le puissant Serializer de Symfony, permet de gérer des cas avancés comme la création de DTO immutables (avec promotion de propriétés dans le constructeur), la gestion de structures imbriquées et de collections, l'application de logiques personnalisées (ex : conversion de chaînes en DateTimeImmutable), et l'adaptation entre différentes conventions de nommage (snake_case ↔ camelCase). Grâce à des exemples concrets en Symfony 7.3, il démontre comment configurer et utiliser l'ObjectMapper pour des transformations de données élégantes et maintenables, tout en intégrant la validation et la gestion des erreurs. Un guide pratique pour optimiser la manipulation de données dans des applications PHP modernes.
L'auteur montre qu’il n’est pas nécessaire de migrer vers TypeScript pour bénéficier de sa rigueur : PHP 8.1+, couplé à des outils d’analyse statique (Psalm, PHPStan) et à des bibliothèques idiomatiques, permet d’obtenir des garanties similaires en typage, validation et maintenabilité. L’article détaille des équivalences concrètes : DTOs (classes typées + validation runtime), énumérations (PHP enums + match), génériques (via docblocks et analyse statique), métadonnées (attributs PHP), validation (Symfony Validator), gestion des erreurs (objets Result ou exceptions), et asynchrone (queues ou Fibers). L’approche est incrémentale, avec des exemples prêts à l’emploi, et met en avant les forces de PHP (écosystème mature, performances) tout en comblant l’écart avec TypeScript sur la sécurité et l’ergonomie. À retenir : combiner typage statique, validation aux frontières et design explicite pour un code PHP aussi robuste et maintenable qu’une base TypeScript, sans tout réécrire.
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.
Symfony 7.3 introduit le composant Object Mapper qui simplifie la transformation d'entités en DTOs. L'auteur montre plusieurs cas d'utilisations, du mapping direct (propriété identique) au mapping avec transformation, en passant par les mapping de types complexes.
Il conclue en discutant des avantages de ce composant.
L'article explique pourquoi il est préférable d'utiliser des objets de transfert de données (DTO) avec les formulaires Symfony plutôt que des entités. Bien que l'utilisation directe des entités dans les formulaires soit simple et efficace pour des opérations CRUD basiques, elle peut devenir complexe et problématique pour des cas d'utilisation plus avancés.
L'auteur illustre cela avec un exemple où un formulaire d'édition d'utilisateur doit gérer des champs d'adresse conditionnels. Utiliser directement les entités nécessite des ajustements complexes, comme des transformateurs de données, et peut mener à des états incohérents des entités.
En revanche, l'utilisation de DTOs permet de séparer clairement les données du formulaire de la logique métier, rendant le code plus maintenable et compréhensible. Les DTOs représentent exactement les données du formulaire, évitant ainsi de modifier les entités pour s'adapter aux besoins du formulaire.
Bien que cela nécessite un peu plus de code pour mapper les données entre les DTOs et les entités, cette approche est plus flexible et évite les inconvénients liés à l'utilisation directe des entités dans les formulaires
L'auteur explique à quoi servent les DTOs et comment les utiliser dans le contexte d'une application Symfony en particulier.
Un article très complet sur les DTO : ce qu'ils sont, à quoi ils servent, les pièges à éviter
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
Une astuce top : utiliser le "type de formulaire Symfony" comme DTO (au lieu d'utiliser un DTO externe comme "réceptacle des données de formulaire"). Bonus : ça permet aussi d'utiliser le type de formulaire comme paramètre d'entrée d'une commande
L'auteur montre l'utilisation des DTOs et des annotations pour la validation de données de requêtes d'API.
Tout est dans le titre
Tout est dans le titre