Discussion :

[ouedmouss]

Je suis en train de developper une appli web avec hibernate.
J'ai ma couche
DAO
Metier
Service
Adaptatation.

Actuellement je me pose plusieurs questions.
-Au vu du travail qu'effectue hibernate, la couche DAO est elle encore necessaire
-Quelle est la grosse différence avec la couche Service et Metier.

Merci pour vos reponse

[bertil]

ta couche DAO va seulement effectuer les operations simple de la base de données, mettre à jour,inserer .... de plus cette couche peut justement etre liée à l'orm que tu utilise, donc si tu change d'orm ou de base de données tu ne modifie que ta couche DAO et tu ne touche pas à ta couche metier.
Tu vas utiliser ta couche DAO dans la couche metier et tu peux ainsi enrichir les traitements en fonction de tes besoins.

par contre je ne sais pas ce que tu apelles exactement couche service, si c'est dans l'optique SOA, la couche service et la couche metier son quasiment la meme chose sauf que dans une approche service, les objets services ne contiennent pas les données de l'appli.

[azerr]

Bonjour,
j'ai poste hier un message concernant l'architecture Service/DAO.
Si tu es interesse, tu peux trouver une description de l'architecture Service/DAO et le decoupage Form/DTO/Bean que j'ai mis en place pour mon projet OpenSource GestCV.

Le site de GesCV : http://gestcv.sourceforge.net/fr/index.html

La partie parlant de Service et DAO :
http://gestcv.sourceforge.net/fr/arc...rvice_dao.html

Angelo

[bertil]

Salut,

Azerr, j'ai plusieurs interrogation concernant le design DTO que je ne connaissais pas. Comment fait tu pour savoir si une relation doit etre chargée. Va t il y avoir une methode qui charge les relation et une qui ne le fait pas ?
En faisant de cette façon ne perd t on pas certaine optimisations je pense par exemple aux JOIN que hibernate peux faire automatiquement.

[azerr]

La notion de DTO se retrouve dans les EJB. Je ne sais pas si tu as eu le temps de lire la partie http://gestcv.sourceforge.net/fr/architecture.html#Form, DTO et Bean de mon site, mais je tente d'expliquer ce decoupage.

Pour repondre a tes questions :

1. Comment fait tu pour savoir si une relation doit etre chargée
=> C'est la couche service qui pilote tout. La couche service qui fait appel au DAO (implemente en hibernate), recupere les Bean (objet mappe dans les fichiers de mapping hibernate). C'est elle qui va forcer le mode lazy des objets (ce que tu appelles le JOIN automatique). Une fois les ou les Beans charges dans la couche service, on construit une DTO a partir de ces Beans.
Generalement une DTO ressemble tres fortement a un Bean. La difference c'est que le Bean est persistant, autrement dit il est surveille par la session factory d'hibernate. Autrement dit, si tu appelles un getter qui est en mode lazy, ceci va declencher une requete dans la base.

A premier abord le decoupage Bean/DTO semble rebarbatif. Au debut j'utilisai uniquement que des Bean. J'ai eu plein de problemes avec le mode lazy. Par exemple, imagine que tu affiches une liste de roles d'un utilisateur dans une JSP. Tu as un UserBean avec un getter getRoles, qui est en mode lazy. Dans ta JSP tu appele ce getRoles qui va executer une requete, mais le probleme c que ta session hibernate n'est plus ouverte a ce moment la (pas de connexion a la base), et ca va forcement planter (apres tu peux utiliser le pattern Open Session in View, pour laisser ouvert la session durant toute ta JSP (voir Hibernate)).

2. Va t il y avoir une methode qui charge les relation et une qui ne le fait
pas ?
Oui tu aurras un service de type findLightUserById and un service de type
findUserById par exemple.

J'espere que j'aurrais repondu correctement a tes questions

Angelo

[bertil]

ok, donc si j'ai bien compris, les join ne sont plus fait en sql, mais son simulés par ta couche service, on perd donc en optimisation coté bd. Mais ça résoud pas mal de problème au niveau des sessions.