IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Hibernate Java Discussion :

Architecture Hibernate DTO


Sujet :

Hibernate Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Étudiant
    Inscrit en
    Avril 2007
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2007
    Messages : 22
    Par défaut Architecture Hibernate DTO
    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.

  2. #2
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : Janvier 2006
    Messages : 365
    Par défaut
    Citation Envoyé par nono44200
    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...

  3. #3
    Membre Expert
    Profil pro
    Inscrit en
    Août 2006
    Messages
    3 276
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 3 276
    Par défaut
    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.

  4. #4
    Membre averti
    Profil pro
    Étudiant
    Inscrit en
    Avril 2007
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2007
    Messages : 22
    Par défaut
    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,
    ++

Discussions similaires

  1. Hibernate , DTO , Dozer, BeanLib, JSP et performance ?
    Par garthos dans le forum Hibernate
    Réponses: 3
    Dernier message: 13/12/2010, 09h18
  2. Réponses: 47
    Dernier message: 04/07/2006, 16h39
  3. [Architecture] n tiers (Spring Hibernate)
    Par tatemilio2 dans le forum Hibernate
    Réponses: 3
    Dernier message: 13/06/2006, 10h16
  4. Réponses: 5
    Dernier message: 12/05/2006, 22h02
  5. [architecture] [DAO] choisir hibernate ou JDO?
    Par Aldo dans le forum Hibernate
    Réponses: 2
    Dernier message: 06/04/2005, 14h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo