couche DAO. Est ce encore necessaire ?

**ouedmouss** · 04/05/2006, 14h29

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** · 04/05/2006, 15h19

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** · 04/05/2006, 16h36

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** · 05/05/2006, 11h10

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** · 05/05/2006, 12h04

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** · 05/05/2006, 12h27

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.

**azerr** · 05/05/2006, 12h43

Non les Join sont bien fait en SQL. Je comprends que mon explication te perturbe, car mes DAO sont implementes en Hibernate. Hibernate te donne la possibilite d'executer des jointures que si tu les demandes. Par contre si tes DAO sont implementes en SQL tu feras des jointures classiques dans tes DAO.

Ton service appellera une ou plusieurs DAO et construira la DTO a partir de tes objets Bean de tes DAO. Il est vrai que mon explication est moins pertinente pour le SQL pur.

Pour moi la base de données doit etre utilise pour faire des jointures tri et pagination et surtout pas le faire en JAVA. Au niveau optimisation ca peut etre catastrophique.

Angelo

**bertil** · 05/05/2006, 15h51

pas de probleme en ce qui concerne les jointures Hibernate. Je t'explique un peu plus precisement ce que j'ai compris. Par exemple pour construire un objet UserDTO dans lequel tu souhaite avoir les roles tu va d'abord recuperer dans ta couche service l'user en question en faisant appel à la DAO. Ensuite tu fait à nouveau appel à la DAO our avoir les role et là tu utilise ces deux infos pour peupler ton objet DTO. Danss ce cas là on a deux select consécutif (le select ... from user et le select ... from role) et donc pas de join.j'ai bien compris ? ou sinon y'a un truc que j'ai loupé

**azerr** · 05/05/2006, 16h33

Oui c exactement ca. Maintenant il n'y a pas de règle stricte. Si dans ton application, tu dois charger tout le temps le user associé avec ses rôles. Il n'y a pas d'hesitation, tu fait ta requete select avec ton join. Maintenant, si tu dois charger une fois le user et une fois le user avec ses roles. Je pense qu'il vaut mieux faire deux DAO (une pour le user et une pour le role), et c'est le service qui appelle les ou la DAO en fonction de ce que tu dois charger.

Angelo

**_steph** · 06/05/2006, 17h53

Bonjour,

Je me permet d'intervenir dans votre discussion. Je ne connais pas bien Hibernate.
N'y a-t-il pas des cas ou les DTO peuvent être des beans Hibernate détachés ou est-ce a éviter et pourquoi?

**azerr** · 07/05/2006, 23h55

Bonjour _steph,
oui en effet, un Bean/DTO pourrait etre fusionne en detachant l'objet.

Pour l'architecture que j'ai l'habitude d'adopter, je decoupe en Bean DTO pour :
1. ne mettre aucun metier dans les Bean (eg : getter qui retournerait l'age d'une personne), mais que dans les DTO.
2. que la structure de la DTO retournée puisse être indépendante de la structure du Bean. Il peut arriver parfois que le mapping hibernate ne suffise pas a tout populer d'un coup les infos d'un Bean. Une DTO peut etre construite a partir de plusieurs autres Bean.
3. eviter d'oublier de detacher l'objet dans le service. Je sais que mes services doivent retournes des DTO, et que dans mes services la conversion Bean/DTO est obligatoire.

Mais ce sont des raisons personnels, et le détachement d'objet peut être applicable.

Angelo

**Kevin12** · 15/03/2007, 19h46

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public void createCollaborateur(Collaborateur collaborateur) {
      Connection connection = null;
      try {
        // Ouverture de la connection 
        connection = MyPoolConnection.getConnection();
        ...
        // Execution de la requête en utilisant la connexion ouverte
        // INSERT INTO T_COLLABORATEUR  ...
        // Commit de la connection
        connection.commit(); 
      }
      catch(SQLException e) {
        // Erreur => Rollback de la connection
        connection.rollback(); 
      }
      finally {
        // Fermeture de la connection
        try { 
            if (connection != null) {
              // Fermeture de la connection
              connection.close(); 
            }
        }
        catch(SQLException e) {}
      }
    }

Est ce qu'il y a un moyen de récupérer la connexion depuis l'ActionForm ? (sans hibernate ni spring). C'est un projet à but pédagogique

**azerr** · 15/03/2007, 20h07

Bonsoir,
je pense que le plus simple (c'est comme ca que je faisais a mes debuts de Struts), c'est d'ouvrir ta connection dans ton ActionForward (au dbut de la methode) de passer ta connection a tes DAO et de fermer la connection a la fin de ton ActionForward.

Mais bon dans le cas d'une application professionnel, je conseille de separer en couche Action/Service/DAO (comme j'ai tente de l'expliquer dans gestcv).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
Ca donnerait : 
public ActionForward save(ActionMapping mapping, ActionForm actionForm, HttpServletRequest request, HttpServletResponse response) throws Exception {
    try {
       Connection connection = MyPoolConnection.getConnection();
       // Appel des DAO
       myDAO.setConnection(connection);
       //
       return mapping.....
     }
     catch(SQLException e) {
        // Erreur => Rollback de la connection
        connection.rollback(); 
      }
      finally {
        // Fermeture de la connection
        try { 
            if (connection != null) {
              // Fermeture de la connection
              connection.close(); 
            }
        }
        catch(SQLException e) {}
      }
      return mapping.....ERROR
}

Angelo

**Kevin12** · 16/03/2007, 13h35

Merci ! C'est ce que je cherchais depuis des semaines.

**nemane82** · 22/07/2008, 15h36

Bonjour,
J'hésite entre l'utilisation d'un DTO ou ne pas faire, je trouve que l'utilisation de DTO nécessite beacoup de temp pour le développeur qui se charger chaque fois de faire populate entre Bean et DTO, y-a-il une autre solution?

couche DAO. Est ce encore necessaire ?

Hibernate Java

Discussions similaires

Partager

Partager