Discussion :

[CharlSka]

Bonjour,

J'ai hésité à reprendre ce topic (plutot interessant) mais le nom n'ayant plus vriament de rapport, j'ai opté pour un nouveau ...

En fait, je suis sur un projet (à la bourre pour être original ) et Hibernate à été choisi, j'ai du m'en occuper en partie (pour le mapping plus particulièrement) et vient maintenant le moment de l'utiliser !
Donc notre "petit" projet Hibernate marche à peu près, je dis à peu près dans la mesure où je ne sais pas utiliser Hibernate et je n'ai donc pas fait tous les tests unitaires nécessaires (juste les get, load, findAll, save, update, delete).
Je dois encore tester les requêtes plus complexes, mais là je ne sais pas vers quel politique m'orienter. Criteria ? HQL ?

(1) SQL je pense que c'est à éviter autant que possible, OK ! Mais entre HQL ou Criteria ? Y a-t-il des différences de performances ? Offrent-ils les mêmes possibilités ?

(2) Je m'interrogeais également sur les objet TableDAO.java sont-ils utilisable et dans quel cas ? Parce que j'ai vu que certaines fonctions de base pouvaient être utilisées par ces classes au lieu d'utilisé la session !

(3) Selon ce que vous me conseiller (Cirteria ou HQL) des adresses de tutos, cours ou autre (FR ou EN) seraient les biens venus, pour voir comment on l'utilise (bien) et avec si possible à fond, enfin je peux rêver

[fr1man]

Je dirais que si les requêtes sont simples, Criteria va bien, sinon je préfère HQL, je trouve ça plus lisible.
Tu trouveras dans la doc Hibernate, pas mal d'exemples te permettant d'apprendre Criteria et Hql.

[CharlSka]

Oui j'ai survolé la doc pour HQL et Criteria, elle a l'air plutot digeste et compréhensible pour une prise en main rapide . Ca me rassure ! Pour a réalisation du mapping, je trouve ca plutot compliqué, surtout que je travail pas avec les cas les plus évidents ...

Donc
(1) je pars sur HQL dans l'urgence ca a l'air bcp plus simple à assimiler que Criteria ! On verra plus tard si il faut y revenir

(2) ? personne n'a d'explications ?

(3) La doc suffira pour l'instant !

[a.snaps]

(2) Je m'interrogeais également sur les objet TableDAO.java sont-ils utilisable et dans quel cas ? Parce que j'ai vu que certaines fonctions de base pouvaient être utilisées par ces classes au lieu d'utilisé la session !

Tu fais référence à la Pattern Data Access Object j'imagine avec TableDAO?
C'est un sujet de discussion incessant ici! Car la pattern DAO n'est plus appliquée comme avant, car

• Une instance retournée par la session hibernate est managée, ainsi toute modification faite à celle-ci sera propagée à la base de données et vraisemblablement persistée ou lancera un Exception (contraint de la base, ...); ce qui n'est pas le "comportement" généralement rencontré avec un DAO.
• A moitier valable ici, car tu utilises Hibernate directement et non JPA, mais l'abstraction du type de base de données, et par extension 98% des query est gérer par Hibernate et non plus par l'implémentation des DAOs. Dans le cas de JPA, c'est même lui qui gère l'abstraction de l'outil ORM, et il reste peu d'intérêt au DAO...

Mais je vois l'avantage suivant, dans le cas d'Hibernate et à moitier pour JPA:

• Le DAO encapsule les requêtes complexes (Queries)! Ainsi la méthode DAO.findValidByReference(String reference) est réutilisable à travers tout le code sans repondre la requête à chaque fois.
• Pour JPA, ces requêtes deviennent des NamedQueries déclarées au niveau de l'entité même! L'avantage qui reste au DAO au niveau de l'encapsulation est la centralisation des appels à ces derniers et, par extension, la gestion de leurs paramètres. Ainsi toute modifications à la "signature" d'une requête (par exemple ajout d'un paramètre) se traduit par la modification de la méthode correspondante au niveau du DAO et par une vérification au moment de la compilation pour le reste du projet...

J'ai un petit post en anglais sur mon blog à ce sujet.
Alex

[CharlSka]

Donc si j'ai bien compris, habituellement (avec le partern DAO) on utiliserait ces classes pour faire les appels, mais maintenant avec Hibernate ce n'est plus nécessaire !? (Je demande parce que je ne suis pas sur d'avoir bien compris tes explications )

En fait je me voulais juste savoir lequel de ces deux appels été correct ou plutot conseillé :

Code :

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

1
2
assDAO = new AssDAO(session);
assure = assDAO.get(new Long("1"));

ou

Code :

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

assure = session.get(Ass.class, new Long("1"));

[a.snaps]

Comme tu utilises Hibernate, je pense que la couche DAO sera toujours utile si tu décides de changer d'ORM, je te conseille donc de la garder. Toutefois:

Code :

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

1
2
 
AssDAO assDao = DaoFactory.getAssDao();

Avec:

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
 
public interface AssDAO {
 
   Ass getAssById(Long id);
 
   Ass getAssByName(String name);
}
 
public class AssDaoHibernateImpl
      implements AssDAO {
 
   private Session session;
 
   public void setSession(Session session) {
      this.session = session;
   }
 
   Ass getAssById(Long id) {
      return session.load(Ass.class, id);
   }
 
   ...
}

Et ton DaoFactory s'occupe de retourné une instance de l'implémentation Hibernate des DAOs après leur avoir injecté la Session.

Alex

[CharlSka]

En fait je prends la suite de quelqu'un qui avait commencer à mettre en place Hibernate et je me rends compte qu'il y a quelques trucs à revoir dans l'utilisation que nous faisons d'Hibernate ...

[a.snaps]

Tes interrogations et autres découvertes m'intéresse!
Si les partager te dis
Alex