Discussion :

[nono44200]

Bonjour,

NB : Je vais essayer d'expliquer mon problème. Ne maitrisant pas encore tout le jargon JAVA/J2EE/Hibernate n'hésitez pas à me demander des précisions !

Voici mon problème :

Contexte : je suis dans une équipe de développeur peu expérimentée en JAVA/J2EE, nous avons un architecte J2EE qui nous a donné des prérogatives mais qui est parti en vacances. Nous faisons face à certains problèmes et nous n'arrivons pas à trouver de solutions.

Sujet : Le site internet est un site de référencement d'acteurs économiques. L'architecture est basée sur les technos suivantes :
MySql, Hibernate, Struts.

L'architecture est la suivante :

Struts (Action, Mapping, JSP)
|
Manager
|
DAO
|
Hibernate (en mode lazy=true)
|
BD MYSQL

Dans la couche hibernate, nous avons les méthodes qui vont intéragir avec la base. Requête etc ...

La couche DAO est simplement un ensemble d'Interfaces qui donnent les méthodes à implémenter dans la couche Hibernate.

La couche Manager effectue les traitements métiers. J'imagine que c'est la couche que l'on appelle plus couramment métier ou services. Cette couche récupère des objets que notre architecte nomme DATA. Ce sont des objets Hibernate.

Dans la couche Manager, nous ouvrons/fermons la session Hibernate, nous utilisons les méthodes DAO etc.

Une fois nos objets DATA(Hibernate) récupérés, nous devons les convertir en des BEANS (nommés par notre architecte des MODEL) (il me semble que le terme plus approprié aurait été DTO) afin de les remonter à notre tier WEB.

Le problème est donc ici. Nos objets Hibernate sont souvent composés d'autres objets Hibernate. Nous ne savons pas par conséquent comment convertir ces objets Hibernate en objet Model(ou plutôt DTO).

Par exemple un objet pays (CountryData) contient une collection d'objets (ZoneTypeData).

Pour l'instant nous avons créé un ensemble de classes qui nous permettent cette conversion. Malheureusement cela ne fonctionne pas très bien. C'est très instable et pas optimum du tout. (problèmes de performances).

Un autre problème se dessine à l'horizon comment enregistrer les changements dans la base. Le tiers WEB a connaissance des objets Model(DTO), nous effectuons des modifications sur ces objets via les méthodes setteurs.
Et ensuite... ?
Devons-nous aller chercher l'objet Hibernate correspondant en effectuant une requête, modifier ses attributs en les remplissant avec les attributs du bean model et effectuer un saveOrUpdate()?
Tout ça me parait super lourd !
J'imagine qu'on s'y prend comme des manches !

J'ai donc cherché une solution à notre (nos) problème(s) en vain. J'ai aperçu des solutions comme Dozer mais je n'ai pas vu beaucoup de doc la dessus et je ne sais même pas si cela va répondre à nos problèmes.

Qu'en pensez-vous ? Quelqu'un a-t-il rencontré des problèmes similaires ?
Sommes-nous à coté de la plaque ?
Et quel est l'intéret de cette couche modèle (DTO) ?
Pourquoi ne pas remonter les objets hibernate jusqu'au tiers WEB.
J'imagine que c'est une question de couplage.
Mais de toute manière même avec cette couche supplémentaire la modification d'un objet Hibernate aura forcément des répercussions jusqu'au tier web.

Je vous avoue que je suis complètement perdu. Si vous pouviez m'éclairer ça serait pas de refus.

Merci d'avance.
Arnaud

Pour résumé : quel moyen pour convertir un objet Hibernate en un BEAN et inversement. Supprimer la couche DTO pose-t-il réellement des problèmes de couplage avec Hibernate 3.0 ?

PS : Désolé si je n'utilise pas les bons termes techniques, j'espère que vous me comprendrez quand même.

[manblaizo]

Un autre problème se dessine à l'horizon comment enregistrer les changements dans la base. Le tiers WEB a connaissance des objets Model(DTO), nous effectuons des modifications sur ces objets via les méthodes setteurs.
Et ensuite... ?
Devons-nous aller chercher l'objet Hibernate correspondant en effectuant une requête, modifier ses attributs en les remplissant avec les attributs du bean model et effectuer un save_or_update()?
Tout ça me parait super lourd !
J'imagine qu'on s'y prend comme des manches !

J'ai donc cherché une solution à notre (nos) problème(s) en vain. J'ai aperçu des solutions comme Dozer mais je n'ai pas vu beaucoup de doc la dessus et je ne sais même pas si cela va répondre à nos problèmes.

Qu'en pensez-vous ? Quelqu'un a-t-il rencontré des problèmes similaires ?
Sommes-nous à coté de la plaque ?
Et quel est l'intéret de cette couche modèle (DTO) ?
Pourquoi ne pas remonter les objets hibernate jusqu'au tiers WEB.
J'imagine que c'est une question de couplage.
Mais de toute manière même avec cette couche supplémentaire la modification d'un objet Hibernate aura forcément des répercussions jusqu'au tier web.

Bonjour,
Je crois que tu as en grande partie répondu à tes questions. C'est une discussion qu'il vous faudrait avoir avec votre architecte pour comprendre ce qui justifie ses choix. A mon avis, pour une architecture aussi simple, il n'y a pas véritablement besoin de DTO, en tout cas pas autant qu'il y aurait de beans mappés par hibernate. L'une des principales simplifications qu'apportent hibernate et les ejb3 par rapport aux ejb2, c'est justement de pouvoir éviter d'avoir à maintenir toute une hiérarchie de classes DTOs qui ne serviraient que de conteneurs des données de classes persistentes. Hibernate permet de travailler avec des objets dit "détachés", que l'on peut renvoyer à la couche présentation, les modifier puis ensuite les réattacher à une session hibernate pour mettre à jour la base de données. Mais bien évidemment, ça introduit un certain couplage, comme tu l'as dit, et il se peut que votre architecte recherche une totale encapsulation. Mais est-ce suffisant ?
Sinon, il y a un pattern dans le monde ejb2, Transfer Object Factory, qui (on le devine) n'est autre qu'une classe factory pour créer tes différent DTOs en remplissant les champs un à un avec les valeurs de ceux de l'objet persistent...

[fr1man]

Je suis assez d'accord avec manblaizo.
Pour ce qui est du couplage :
les objets Hibernate étant de simples beans, le jour où tu voudras supprimer Hibernate, tu pourras toujours utiliser tes beans et les "remplir" autrement, par JDBC ou tout autre framework de persistance.
Je ne vois donc pas de problème, étant donné que ton architecture est bien séparée en couches.

[nono44200]

Merci Manblaizon pour cette réponse rapide.

Ok donc si je comprends les DTO sont utilisés lorsque l'on souhaite par exemple transférer des objets via RMI.
Je crois qu'en effet dans notre architecture ce n'est pas forcément utile, surtout que nous travaillons sur un projet relativement simple.

Je ne sais pas quelles ont put être les motivations de notre architecte.

Le problème est que nous allons sans doute devoir garder cette architecture. Je ne peux pas prendre la décision de modifier l'architecture .... je suis que stagiaire

Par conséquent, quelles sont les solutions possibles (simples et rapides de préférence) dans ce type d'architecture ?
Dozer , ... ?
Le but étant de ne pas faire exploser les temps de dév !

Savez-vous où je pourrai trouver des exemples de code avec ce type d'architecture ?

Encore merci,
++