On Wed, 18 Jan 2012 14:59:57 +0100 Yannick Martel <martel@codelutin.com> wrote:
L'idée serait donc de créer un helper json dans topia. Ca eviera a chaque projet de devoir creer des dto pour ce seul besoin.
Je suis pas convaincu par l'approche : on a un probleme, pour le moment specifique à notre utilisation du plugin JSON de struts, mais des lors ou il faudra serializer dans un autre langage (xml, yaml, etc ...), devra-t-on faire la meme chose ?
Oui, il faudra implanter un helper specifique, qui pourra s'appuyer sur la bonne librairie pour ce langage. Par exemple on on remonte le TopiaContext mais il est marque transient donc la serialization json ne devrait pas le prendre donc c'est le plugin qui est en faute. Il faut donc utilise une librairie qui fonctionne convenablement pour implanter le TopiaJsonHelper. De plus si on veut utiliser Topia dans un autre context que struts et faire du json, on fait comment ? Il faudra reecrire la serialization json pour ce projet car plus de plugin struts ? Je ne dis pas qu'il faut anticiper un besoin qu'on a pas (loin de moi cette idee). Je dis juste qu'on a un problème actuellement qu'on peut résoudre facilement en implantant un Helper en utilisant la bonne librairie. En resolvant ce probleme de cette facon, on ouvre la librairie a tout plein d'usage.
Ma vision du probleme, c'est qu'on remonte la terre et le monde avec les entités. Loin de moi l'envie de relancer un débat qui semble avoir deja eu lieu à plusieurs reprises.
non tout ce qui est en 'trop' est transient
L'approche que j'ai sur cette problematique, c'est de créer des DTOs avec nos entités. Je vois l'utilisation d'un DTO comme une vue sur une entité (ou plusieurs entités), et c'est exactement ce que l'on désire ici : ne voir que certaines propriétés, celles propres à l'entité, que l'on ecrit dans le model (+ potentiellement l'id, qui est pas explicitement indiqué dans le model).
Et le jour ou ce DTO ne plait pas a ta librairie du framework que tu utilises tu fais un autre DTO encore plus mieux ? Je pense que tu ne fais que reporter le probleme. En plus dans ce cas tu genere un objet DTO qui ne sert qu'a permettre a une mauvaise librairie de faire une serialization Json. Donc tu crées un objet, tu copies toutes les données pour le mettre a la poubelle juste apres :(. C'est pas un peu couteux, surtout lorsque tu as une solution qui te permet de faire la meme chose sans creer d'objet intermediaire
Pourquoi ne pas voir alors dans le EntityDTOTransformer un ajout de la propriété "id" qui correspondrait au topiaId de l'entité, ainsi qu'une operation permettant la creation du DTO depuis l'entité pour en faire la copie directement et simplement ? Ou alors j'ai pas compris l'utilité de ce transformer par rapport au "DTOTransformer".
Ca c'est une autre chose, simplifier la creer d'un DTO qui existe déjà et lui ajouter un id qui permettrait de le rendre reellement utilisable. Vu le cout du developpement et le gain que cela peut avoir je suis plutot pour. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com