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é !
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.
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é ?
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 !
Comments
Comments are closed.
Merci de nous rappeler à quel point doctrine peut nous emmerder :-D
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é !
Super talk, apporte beaucoup de clarté dans le concept du ValueObject ! Je ferai dorénavant attention à mes patterns afin d'en utiliser davantage.
J'adhère complètement!
présentation claire et dynamique mais je n'ai pas totalement accroché au sujet (implémentation d'un pattern et ces limites)
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.
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é ?
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 !