Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Et bien tu parlais au départ d'utiliser directement les objets Hibernate sans créer de DTO, c'est dans ce cadre que je disais que dans le cas d'un changement de framework ( en enlevant Hibernate par exemple ) ton application aurait besoin d'un assez gros travail pour changer.Envoyé par mehdi_31
Si tu utilises les DTO, seule la partie qui "renseigne" les DTO est à changer.
A+
Hello,
Je suis entièrement d'accord.
Mais il faut bien penser à implémenter les objets DTOs dans un package commons (qui sera compilé dans un archive à part) afin que ceux ci reste indépendant de la couche persistance et de l'ensemble des autres couches de l'application...
Aussi je pense que le mapping à l'entrée de chaque couche (avec des recopie) permet de pouvoir décoreller les couches et apporte une de la souplesse à la modularité de l'application.
Surtout qu'il existe des APIs permettant de faire de la recopie de maniere transparente (commons.Collection, si je me souviens bien). Donc peu couteuse en charge de développement.
Je vais ajouter mon grain de sel...
DTO ou pas, la couche service et les objets métiers sont définis par des interfaces. Si lors de l'utilisation d'hibernate le POJO utilisé s'adapte à l'interface tant mieux, sinon je passe par un DTO. Je ne passe jamais par un DTO pour le plaisir et je le fais uniquement lorsque c'est nécessaire.
Alesque : et le jour où ton application abandonne Hibernate, ton POJO il part avec, et toutes tes couches qui en était dépendantes seront à revoir; dans tous les traitements tu devras modifier les utilisations des POJO.
Sans parler du fait que mélanger POJOs et DTOs est bien pire selon moi que de n'avoir aucun DTO; au final tu te retrouves avec un ensemble de classes, sans savoir si c'est un DTO ou un POJO Hibernate..
C'est exact, mais cela n'arrivera peut être jamais... alors pourquoi produire autant d'efforts pour une eventualité qui ne se produira peut être pas. Je ne suis pas là pour programmer une oeuvre d'art, mais pour être productif et obtenir le niveau de performances exigés avec le minimum de défauts.Alesque : et le jour où ton application abandonne Hibernate, ton POJO il part avec, et toutes tes couches qui en était dépendantes seront à revoir; dans tous les traitements tu devras modifier les utilisations des POJO.
Au final j'obtiens quand même une programmation en couche liées par des interfaces. C'est l'implémentation qui diffère.
Dans le code les DTO se repèrent facilement puisque j'utilise la convention xxxDTO. De toute façon dans la couche du dessous je manipule des interfaces donc DTO ou POJO je m'en fous un peu.au final tu te retrouves avec un ensemble de classes, sans savoir si c'est un DTO ou un POJO Hibernate.
Au cours des préliminaires du dev d'une appli, je flanne sur le forum pour trouer qqs infos, je tombe sur ce sujet et la horreur, je comprend plus rien à la différence entre POJO et DTO et ce que je devrais faire dans mon appli.
Dans mon cas, l'appli se base sur hibernate avec des objects POJO et un mapping XML. Mes POJO ne sont donc en rien couplé avec Hibernate !
Mes POJO (ou alors DTO alors) remonte jusqu'a ma couche de facade pour être récupérés par mon objet model et pouvoir être affiché dans des composants graphiques (MVP)
En quoi une telle architecture pose problème, étant donné que les POJO ne sont que des objets avec getter/setter ?
Si je doit changer une couche, ba il suffit de continuer a travailler avec ces mêmes objets ! et si un objet doit changer, de tout facon, toutes les couches en seront impactées !
Maintenant, pour ne pas être couplé avec Hibernate dans mon DAOn je vais passer sur JPA. La je ne suis pas sur que je pourrais continuer à utiliser un mapping XML, mais plutot des annotations.
Mais cela pose t'il vraiment problème vu que l'important dans ces objets c'est les attributs et les methodes pour y accéder ?
La je suis un peu paumé, si avez qqs info a m'apporter ?
Merci
Ce que tu appelles POJO, est un DTOEtant donné que tu le crées de toute pièce, à partir de ce que Hibernate te retourne.
Quand je parlais de POJO Hibernate, je parlais des classes de mapping Hibernate, qu'il ne faut pas balader partout dans l'application; à partir de celle-ci, il faut générer un DTO.
J'en profite pour rebondir sur ce qu'a dit Alesque :
Tout est dans le "peut-être" de tes phrases. L'évolution, la portabilité, la maintenance seront autant de phases qu'une telle architecture impactera.C'est exact, mais cela n'arrivera peut être jamais... alors pourquoi produire autant d'efforts pour une eventualité qui ne se produira peut être pas. Je ne suis pas là pour programmer une oeuvre d'art, mais pour être productif et obtenir le niveau de performances exigés avec le minimum de défauts.
Au final j'obtiens quand même une programmation en couche liées par des interfaces. C'est l'implémentation qui diffère.
Je n'aime pas les systèmes hybrides, car ça implique que tu ailles modifier tes structures à deux endroits différents, en cas d'évolution par exemple; et comment ça va se passer, le jour où tu devras modifier des relations entre tes objets, tu vas avoir des dépendances entre des DTO et des POJO Hibernate ? ouch....Dans le code les DTO se repèrent facilement puisque j'utilise la convention xxxDTO. De toute façon dans la couche du dessous je manipule des interfaces donc DTO ou POJO je m'en fous un peu.
Je ne suis pas sur car je ne crée pas vraiment mon DTO, je cast mon POJO Hibernate, dans le un object de type de mon DTOCe que tu appelles POJO, est un DTO
Quand je parlais de POJO Hibernate, je parlais des classes de mapping Hibernate, qu'il ne faut pas balader partout dans l'application; à partir de celle-ci, il faut générer un DTO.
Oula, je commence a être de plus en perdu, sur ce qu'il faut que je fasse et que je fasse pas. D'autant que les paramettres de performances, de maintenance et d'evolutivité sont tres important dans mon cas
Ce qui compte pour l'evolutabilité, c'est d'avoir un DTO dans tes couches, et non un POJO Hibernate. Après, la façon dont tu le crées, que ce soit un cast, ou autre, ça n'a pas tant d'importance que ça. Bien que je trouve ça un peu choquant de caster un objet en un autre o_O Ca ajoute des dépendances j'imagine entre tes DTO et tes POJO Hibernate, ton POJO Hibernate extends ton DTO ?
En faite, j'ai créé un objet java avec juste des attribut + getter/setter. appelles ca comme tu vaux, pour moi c'est un pojo.
Pour le mapping, c'est un fichier xml qui s'en charge en fesant ref a ce pojo.
Et pour finir quand je fais une requete hibernate (via spring), exemple un get(), je transtype (et non cast excuse moi) l'objet dans le type de mon objet.
Donc si je ne me trompe pas, je continue a travailler avec mon objet hibernate, alors que mes couche domaine et présentation pensent travailler avec un objet simple !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
=> Soit pas tant de problème de dépendance que ca entre les couches et j'ai juste a faire attention de ne pas faire n'importe quoi avec mes lazyinit pour ne pas executer des requetes a tout va.
Je me trompe ?
Oui je vois, tu es donc confronté à un danger; que se passe-t-il le jour où tu ajoutes un attribut, ou tu changes le nom d'un attribut au niveua de tes classes hibernate; il faut tout changer dans ton application ?
Ou pire, le jour où tu abandonnes Hibernate !
Ba si je rajoute un attribut a ma classe personne, il faudra de toute facon que toutes les couches devant utiliser cet attribut soit modifiées, quelque soit la solution
Et si je n'utilise pas cet attribut dans les autres couches, elles n'y verront que du feu.
Si je remplace hibernate, il me suffira de réécrire mon DAO, vu que c'est la seule couche qui y fait référence et veiller a ce que les méthodes de mon nouveau DAO renvoient bien un objet de type personne, d'autant que c'est mon interface qui le dit, hibernate ou autre.
Je me trompe ? Tu me mets le doute
Hm je crois qu'on ne parle pas tout à fait de la même chose.
Il y a selon moi une couche dite transverse, extrêmement importante dans les applications, qui contient tous les objets et classes communes à toute l'application.
Dans cette couche, on trouve alors les DTO; le but est vraiment d'avoir une application dans l'ensemble pérène, quelque soit la solution utiliser dans une des couches.
Si tu places ta couche "hibernate", à moitié en transverse, à moitié en couche basse; il y a comme un problème de philosophie quelque part qui me gène.
De plus, les DTO sont censés être beaucoup plus légers que les objets Hibernate. Dans un objet Hibernate, tu as un ensemble de données qui ne sont pas utiles tout le temps; par exemple des sous-listes, des attributs ne servant que ponctuellement, etc etc. Il est donc, à mon avis, toujours plus interessant d'avoir une série d'objets DTO "simplifiés au maximum", collant parfaitement à leur utilisation, afin d'alléger au maximum la taille des transferts entre couches.
Par exemple :
Tu as une application qui gère des voitures d'occasion.
Tu décides d'afficher ces voitures, par liste, lors d'une recherche multicritère.
Voici mon raisonnement :
1) Appeller un service "métier" à partir du front, pour récupérer une collection d'objet DTO de type "DTOListeVoiture", objets ne contenant QUE les informations utiles à l'affichage de la liste.
2) Ce service métier ne fait qu'appeller la couche basse via un service, qui est gérée par Hibernate par exemple.
3) Hibernate lui n'agit que dans la couche basse. A ce niveau, on récupère une liste d'objets complexes de voitures; à partir de cette liste, lourde à manipuler, on génère des listes simplifiés de DTOListeVoiture, qu'on renvoit. Résultat, on ne transfert QUE ce dont on a besoin, et on libère beaucoup plus vite les objets lourds.
Maintenant, prenons un cas d'évolution : tu dois ajouter dans ta base, un élément à ta voiture : le nombre de portes. Tu dois également l'afficher sur la liste.
1) Premièrement, modifier le DTOListe en ajoutant un champ. Mettre une valeur par défaut, afin de permettre à quelqu'un de developper le front, sans même que le back ne soit encore au point.
2) Modifier ton mapping et ta base. Tes objets Hibernate ont maintenant l'attribut qu'il te manquait.
3) Modifier la méthode de ta couche basse qui retourne la liste de DTO. Tes DTO ont maintenant l'information renseignée. Enlever le paramètre par défaut que tu avais mit en 1).
Ca y est, c'est fini. C'est un peu plus "lourd", mais au final, pas tant que ça; tu ajoutes la possibilité de travailler directement sur le front avec des informations déjà mise à jour dans leur état final. Tu peux passer autant de temps que tu veux sur les couches basses, ça n'a pas d'importance, quelqu'un peu travailler sur la couche haute, et faire tout ce qu'il veut, des présentations différentes, etc.
Que penses-tu de cette vision des choses ?
Merci pour cette réponse tres complète.
En faite je pense qu'on dit a peu pres la même chose finalement
J'ai du mal m'exprimer, car c'est exactement ce que je fais
Mes objets communs, avec leur fichier de mapping, sont dans un package séparé et sont utiliser dans toute les couches de l'application.
Non, comme je le disais hibernate n'intervient que donc ma couche DAO.
Enfaite tout ca que tu décris par la suite représente exactement l'architecture mise en place dans mon application.
La différence est que ne créant pas de "vrai" DTO, je transporte directement les objets "lourd" renvoyés par Hibernate, ce qui alourdi énormement les transferts entre les couches.
Je comprend donc bien l'intéret de créer des objets optimisés pour les faire remonter vers mes couches hautes.
Surtout que je vais passer sur une solution JPA, alors je serais bien obligé de créer des DTO pour ne pas véhiculer les POJO polués d'annotation JPA.
Je pense avoir bien saisie le problème du transfert d'objet entre "persistance" et couche métier, Mais dans ce sujet, certaines personnes font aussi du recopiage d'objet entre le métier et la présentation ! J'en vois pas trop l'interet, surtout qu'avec du dev swing, l'objet retourné par le métier et ensuite transformer dans le "model".
Ca commence a s'eclaircir un petit peu
Encore merci à toi KiLVaiDeN
ce post retrace exactement mon questionnement vis-à-vis d'une application que je développe.
cependant je me demande si c'est du coup réellement nécessaire sur une application d'un vingtaine de tables avec chacune entre 3 et 6 attributs?
De plus, le nombre de lignes renvoyées par mes requêtes ne dépassera que rarement la vingtaine de ligne. Ajouté au fait que cette application sera interne à l'entreprise où je travaille, j'ai beaucoup de doutes quand à l'utilité de créé des DTO...
Les DTO seront dans la majorité des cas une simple recopie de mes POJO sauf si je créé un DTO pour chacun des objets dont j'ai besoin...
J'en reviens à la même idée soulevée plus haut qu'avec hibernate, l'intérêt des DTO réside seulement dans le poids des objets passés à al couche métier. si je n'utilise plus Hibernate, je change mes DAO et basta non?
POJO + Serializable = DTO
Il suffit de mettre tes POJO Serializable donc pas besoin de re-définir des DTO.
Je pense que le pattern DTO avec Hibernate ne sert pas a grand chose tant qu'on initialize dans la couche DAO ce qu'on utilise plus tard..
1- Même si ton DTO comporte moins de propriété que ton POJO cela n'est pas grave suffit d'afficher (couche présentation) ce qui est nécessaire
2- Si on ajoute une nouvelle colonne => nouvelle propriété dans ton POJO hibernate c'est tout.
3- Il faut centraliser l'accès aux données dans une couche DAO si jamais on change d'ORM alors on change que les couche DAO that's all.
:-)
ce qui est étrange c'est que justement hibernate créé les POJO avec l'interface Serializable :
par contre il ne créé pas le serialversionUID nécessaire...
Code : Sélectionner tout - Visualiser dans une fenêtre à part public class Module implements java.io.Serializable {
Un warning indique à cet effet :
pourtant, j'utilise un champ timestamp pour gérer les accès concurrents sur les objets...
Code : Sélectionner tout - Visualiser dans une fenêtre à part The serializable class Module does not declare a static final serialVersionUID field of type long
cela veut-il dire que pour hibernate POJO = DTO (car il implemente Serializable) ?
?? Tu va plus perdre du temps à recréer une nouvelle liste alégée que de recopier une référence vers la couche supérieur, de toute façon on détruit l'objet complexe apres l'affichage, je ne vois pas le gain mémoire??
Voici d'autres éléments pour alimenter ta réflexion :
http://www.developpez.net/forums/d47...le-conception/
http://www.developpez.net/forums/d70...bjets-metiers/
Si tu dois créer un jeu de classes identiques aux objets d'hibernate juste pour avoir de l'abstraction, perso je trouve que ça n'en vaut pas du tout la peine.cependant je me demande si c'est du coup réellement nécessaire sur une application d'un vingtaine de tables avec chacune entre 3 et 6 attributs?
De plus, le nombre de lignes renvoyées par mes requêtes ne dépassera que rarement la vingtaine de ligne. Ajouté au fait que cette application sera interne à l'entreprise où je travaille, j'ai beaucoup de doutes quand à l'utilité de créé des DTO...
Les DTO seront dans la majorité des cas une simple recopie de mes POJO sauf si je créé un DTO pour chacun des objets dont j'ai besoin...
Ca te fait faire des choses à double, et c'est peut être pas nécessaire.
Il y a bien des cas ou l'on souhaite "éjecter" hibernate de ses POJO. Personnellement j'ai eu des soucis lorsque je devais faire de l'affichage ou laisser l'utilisateur modifier une entité à l'aide d'une interface graphique.J'en reviens à la même idée soulevée plus haut qu'avec hibernate, l'intérêt des DTO réside seulement dans le poids des objets passés à al couche métier. si je n'utilise plus Hibernate, je change mes DAO et basta non?
Le cas idéal d'utilisation de hibernate, c'est tu ouvres une session, tu fais ce que t'as à faire (chargements / updates) et tu fermes la session.
Tous les objets hibernates qui sortent de ce contexte sont explosifs dans le sens où :
-Les changements ne sont plus trackés (particulièrement délicat en cas de delete-orphans sur les collections rattachées).
-Le lazy-loading provoque l'infâme LazyInitializationException .
Tout ça pour dire que si tu souhaites utiliser tes objets hibernate dans une GUI à cheval sur plusieurs sessions, sois très prudent.
Répondre avec citation
Partager