Le Wed, 18 Jan 2012 17:33:34 +0100, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
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 suis justement pas convaincu par le fait d'ecrire la serialization json ou autre alors que le framework qu'on utilise est censé le gérer.
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
Le jour ou mon DTO ne plaira plus, ce ne doit pas etre à cause du framework, mais parce que mon besoin a changé. Je me suis peut etre mal exprimé sur ma vision du DTO, mais si je prends un exemple, c'est avoir un objet "Company" avec plusieurs propriétés : name, address, postalCode, city, country, leader, activityDomain et une List<Employee>. Si toutes ces données sont utiles à la création ou à l'affichage de la company, dans un listing des Companies, on ne peut vouloir afficher que le name, country et leader. Dans ce cas là, l'utilisation d'un DTO ne contenant que les champs souhaités peut etre propice. (Je passe l'exemple avec une grappe d'objets pouvant provenir de employee). Autre exemple, un simple User, en remontant l'entité, on remonte toutes les infos dont le mot de passe. L'interet du DTO, c'est aussi de pouvoir masquer ce genre d'informations. Transient ou pas, les informations liées à l'entité sont aujourd'hui remontées, et je trouve pas que cela soit une bonne chose. Ensuite, que mon framework d'UI soit struts, tapestry, gwt, ou autre, le besoin restera toujours le meme. Le probleme n'est donc pas déporté, car non lié au framework. Et donc, ma phrase "c'est exactement ce que l'on désire ici" était censé etre cet exemple :) -- Yannick <martel@codelutin.com> Société Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com