Qu'est-ce qu'un ValueObject, quand et comment l'utiliser ? Nous allons faire le tour des avantages et inconvénients de cette méthode de représentation, avec des exemples concrets sur l'utilisation avec Doctrine 2.5.
Conférence donnée lors du Forum 2015, ayant eu lieu les 23 et 24 novembre 2015.
Utilisateur avancé de PHP, Damien est développeur Web depuis une dizaine d'années, et touche aussi bien aux gros backend qui tâchent qu'au développement front avec Javascript. Aujourd'hui expert Symfony et Elasticsearch au sein de JoliCode, il est un habitué des meetups Parisien et partage son temps libre entre les concerts et les jeux-vidéo.
Commentaires
Merci de nous rappeler à quel point doctrine peut nous emmerder :-D
Anonyme, le 24/11/2015
Bonne introduction mais je suis resté bloqué sur quelques détails : l'exemple fil rouge du talk était un bon exemple de la dualité VO/Entité (selon le contexte) et ça n'a pas été expliqué, ce qui explique la question à la fin ("comment stocker la liste des types de capsules" - dans le monde de tous les jours il y'a une liste définie des capsules donc source de confusion). Détails : utiliser "final" pour l'encapsulation alors que la propriété est privée (donc pas modifiable par une sous-classe) tue un peu l'exemple (bien que je n'ai rien contre "final"). Et enfin les types custom doctrine marchent très bien pour des VO simples (par ex. des VO qui wrappent une valeur simple, e.g. une somme d'argent, etc.), ça vaudrait le coup de les mentionner selon moi. À part ces détails j'ai beaucoup aimé !
Matthieu Napoli, le 25/11/2015
Super talk, apporte beaucoup de clarté dans le concept du ValueObject ! Je ferai dorénavant attention à mes patterns afin d'en utiliser davantage.
joindin@cedvan.com, le 25/11/2015
J'adhère complètement!
Samuel ROZE, le 25/11/2015
présentation claire et dynamique mais je n'ai pas totalement accroché au sujet (implémentation d'un pattern et ces limites)
Cédric Lécuret, le 25/11/2015
TL;DR : J'ai bien aimé la conf mais j'ai trouvé l'exemple relativement mal choisi.
Il permet une bonne dynamique, des vannes bien menées, etc, mais dans les faits, c'était pas le meilleur choix possible pour parler de ValueObject.
Lorsqu'on en vient à vouloir filtrer par VO, ou en avoir une liste... finalement c'est une entité et puis c'est tout.
Du coup on se retrouve à s'embourber dans des implémentations Doctrine pas folles par rapport aux besoins métiers qui correspondent plus, d'un point de vue Doctrine, à de vrais entités.
Splitter les vrais objets métiers (où on aurait des VO et agrégats) versus la représentation entité Doctrine aurait pu sauver l'exemple mais hors scope et beaucoup trop long à expliquer.
Olivier Madre, le 26/11/2015
Je rejoins certains commentaires, il en ressort pour moi qu'il reste difficile de définir ce qui fait un bon client pour un VO. Dans les faits j'ai surtout du mal à imaginer un concept qui ne vaut pas la peine d'être identifié. Peut-être plus axer la présentation sur cette dualité VO / Entité ?
Jérémy, le 29/11/2015
Je rejoins certains commentaires : l'explication théorique est très claire (mais ça, j'avais pas besoin d'un talk pour l'avoir) et l'exemple pris n'était pas le meilleur...j'aurai apprécié un vrai retour d'XP avec quelques vrais exemples, pour mieux cerner l'utilité de la chose dans la vraie vie !
Commentaires