couche DAO. Est ce encore necessaire ?

Version imprimable

04/05/2006, 13h29
ouedmouss

couche DAO. Est ce encore necessaire ?

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
04/05/2006, 14h19
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.
04/05/2006, 15h36
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
05/05/2006, 10h10
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.
05/05/2006, 11h04
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
05/05/2006, 11h27
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.
05/05/2006, 11h43
azerr

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
05/05/2006, 14h51
bertil

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é
05/05/2006, 15h33
azerr

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
06/05/2006, 16h53
_steph

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?
07/05/2006, 22h55
azerr

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

Code:

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

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:

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

16/03/2007, 12h35
Kevin12

Merci ! C'est ce que je cherchais depuis des semaines.
22/07/2008, 14h36
nemane82

L'utilisation de DTO n'est pas couteuse

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?