Discussion :

[cisco]

Bonjour
Je suis à la recherche de “bonne pratique” pour implémenter des DAO avec JPA.
(J’utilise Spring et Hibernate)
Il y a bien des bonnes idées dans la doc de référence de spring, mais je trouve quand même l’API de JPA « pauvre »
Je suis pour l’instant en test avec des DAO générique de google :
http://code.google.com/p/generic-dao/
L’API est vraiment mieux, c’est puissant, mais je trouve dommage que les entity doivent implémenter une interface spécifique.

Quel sont vos bonne pratique ?

[djo.mos]

Bonjour.
Veux tu expliquer s'il te plaît ce que tu veux dire par API pauvre ? DAns son contexte (la persistance des données), je ne vois pas comment l'API de JPA est pauvre, excepté le manque de la recherche par Criteria, comme celle offerte par Hibernate par exemple, et ça, c'est prévue pour JPA 2.0.

Sinon, de point de vue pratique, je n'utilise jamais les classes Templates ou Support de Spring: je préfère garder mes DAOs JPA indépendants de Spring qui se contente juste de leur injecter un EntityManager. Le reste (listing, ajout, màj et suppression), je le fais avec l'API nue de JPA.

Autre chose: dans 99% des cas, mes DAOs JPA sont des coques vides: tout le boulot est réalisé par un DAO générique et abstrait concocté et développé par mes soins qui fait tout le sale boulot. En général, dans mes DAOs concret, soit je me contente d'hériter de ce DAO abstrait, soit j'y ajoute quelques recherches via des requêtes nommés et le tour est joué.
Merci les génériques et l'API de reflection de Java

Dans l'attente de plus d'explications, @+ !

[a.snaps]

Pareil pour moi: http://jroller.com/greenhorn/entry/uberdao_for_jpa
Même si entre temps il s'est pas mal enrichi...
Mais je suis toujours perplexe quant à l'utilité de DAO (que je préfère d'ailleur appeler Repository dans un contexte d'ORM). J'ai également une API qui vérifie si un persist ou merge est nécessaire. Mais le dernier retournant l'entitée managée cela ne facilite rien...
De plus, comme j'utilise Hibernate, dès que j'ai besoin des "Filter"s je me retrouve à injecter le PersistenceContext dans mes Façades. Ou dès que je dois intéragir avec le cache (L1 ou L2), je l'injecte dans mes Services...
Mais pour ce qui est "fetch plan" la couche prend tout son sens!
Suis toujours mitigé
Alex

[djo.mos]

Bonjour.
@Alexander: J'ai vu l'exemple dans ton blog et c'est exactement ça ! enfin presque, y'a bien sur quelques ptites differences mais le principe est là !
Ah, jolie la vérification du nom de la table via reflection + annotation Entity ! Moi, j'utilisais bêtement le nom de la classe :-).

Mais je suis toujours perplexe quant à l'utilité de DAO (que je préfère d'ailleur appeler Repository dans un contexte d'ORM).

Euh ... Comment veux tu communiquer avec ta DB autrement ?

J'ai également une API qui vérifie si un persist ou merge est nécessaire. Mais le dernier retournant l'entitée managée cela ne facilite rien...

Ha ! Je connais trop bien ça ! J'en ai vu des vertes et des pas mures ! La solution est Spring + Extended Entity Manager.

De plus, comme j'utilise Hibernate, dès que j'ai besoin des "Filter"s je me retrouve à injecter le PersistenceContext dans mes Façades.

Là je comprends plus rien ... J'ai moi même eu besoin de l'API Criteria d'Hibernate dans un contexte JPA et je l'ai implémenté dans le DAO (logique, non ? bon, mais môche quand même ...)

Ou dès que je dois intéragir avec le cache (L1 ou L2), je l'injecte dans mes Services...

Tu as d'autres applications qui écrivent dans ta DB ?

Mais pour ce qui est "fetch plan" la couche prend tout son sens!

huh ? tu parles du fetch mode (lazy/eager) ?

Suis toujours mitigé

Ah oui !

@+

[a.snaps]

Bonjour.
@Alexander: J'ai vu l'exemple dans ton blog et c'est exactement ça ! enfin presque, y'a bien sur quelques ptites differences mais le principe est là !
Ah, jolie la vérification du nom de la table via reflection + annotation Entity ! Moi, j'utilisais bêtement le nom de la classe :-).


Euh ... Comment veux tu communiquer avec ta DB autrement ?

En utilisant l'entitymanager directement et des namedquery'es

Ha ! Je connais trop bien ça ! J'en ai vu des vertes et des pas mures ! La solution est Spring + Extended Entity Manager.

Vais y jeter un oeil...

Là je comprends plus rien ... J'ai moi même eu besoin de l'API Criteria d'Hibernate dans un contexte JPA et je l'ai implémenté dans le DAO (logique, non ? bon, mais môche quand même ...)

Je parle des filters: http://www.hibernate.org/hib_docs/re...l/filters.html

Tu as d'autres applications qui écrivent dans ta DB ?

Oui, mais ce n'est pas pour ça. Plus pour la gestion de mémoire et autre lors de batch....

huh ? tu parles du fetch mode (lazy/eager) ?

Oui, mais des méthodes genres:

Code :

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

1
2
CommandeDAO.getCommandeParId(Long): Commande
CommandeDAO.getCommandeEtLigneParId(Long): Commande

Ou la seconde prends les lignes de commande associées en une seule query DB

Ah oui !

@+

[ndp]

une petite discussion interessante a lire:

http://www.fabiokung.com/2007/11/12/...-repositories/

C'est sur le concepte de Repository/DAO. Je suis tombe dessus, quand je cherchais egalement des infos sur JPA/Dao/Repository.

[denisjava]

Grand débat...

Peut etre qu'il faut admettre finallement que la couche DAO existe mais elle est générique (complètement): la classe proncipale de votre DAO s'appelle l'entityManager qui couvre tous vos besoins: lecture, sauvegarde, modificaiton (dirty checking), suppression, et recherche.

L'usage de l'entity manager dans la couche service (ou métier si vous préférez), ne me gène pas ou en tout cas pas plus que l'usage d'une méthode ProductDAO.getProduct(id); d'autant plus qu'il s'agit bien d'une norme, contrairement à l'objet session d'hibernate qui fait exactement la meme chose mais induisait une dépendance vers un framework non normalisé.

la question est donc de savoir s'il est préférable d'ecrire:

Code :

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

1
2
3
4
 
public List<Client> rechercheClientParVille(String ville) {
  return ClientDAO.listeClientParVille(ville);
}

ou

Code :

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

1
2
3
 
public List<Client> rechercheClientParVille(String ville) {
  return entityManager.createQuery("From Client c where c.ville=:ville").setParamater("ville",ville).list()

pour moi, la deuxième solution est vraiment envisageable d'autant qu'ejbql est un langage de requetage objet indépendant du mondèle de stockage

Voila mon avis :-)
Mais c'est un sujet polémique !
Le DAO ne disparait pas, JPA vous en fournie un totalement générique ! pourquoi ne pas l'utiliser.

Bonjour
Je suis à la recherche de “bonne pratique” pour implémenter des DAO avec JPA.
(J’utilise Spring et Hibernate)
Il y a bien des bonnes idées dans la doc de référence de spring, mais je trouve quand même l’API de JPA « pauvre »
Je suis pour l’instant en test avec des DAO générique de google :
http://code.google.com/p/generic-dao/
L’API est vraiment mieux, c’est puissant, mais je trouve dommage que les entity doivent implémenter une interface spécifique.

Quel sont vos bonne pratique ?

[djo.mos]

Bonjour.
En y allant à ta façon, c'est vrai su'on utilise JPA-QL qui est Objet et indépendant de la base de données. Toutefois, tu lies ta couche Services irrémediablement à un API de persistance spécifique (JPA) et tu ne pourras pas les réutiliser dans un autre projet avec JDBC/Spring JDBC/Toplink/Hibernate/JDO/etc. comme couche de persistance d'où la nécessité de l'abstraction offerte par la couche DAO.

[denisjava]

Bonjour.
tu ne pourras pas les réutiliser dans un autre projet avec JDBC/Spring JDBC/Toplink/Hibernate/JDO/etc. comme couche de persistance d'où la nécessité de l'abstraction offerte par la couche DAO.

oui, c'est juste. Si vous avez besoin de porter vos applications en utilisant d'autres technos, alors le dao est nécessaire mais il va se résumer à Peau de chagrin... reste simplement pour vous à savoir si cela correspond à votre besoin... A force de mettre des couches des indirections etout etout dans tous les sens on perd complètement les développeurs :-) mais ce que dis djo.mos est très juste.

[ndp]

Sur mon projet actuel, on pourrait concretement supprimer cette couche DAO. Ca part du constat que dans notre cas, il n'y a pas de changement du support de persistence, la seule grande revolution de ce cote la, ca a ete une montee de version du sgbd.

[denisjava]

Sans remettre en cause le bien fondé du sempiternel découpage Presentation/Service/dao (avec les variantes qu'il comporte), il ne faut pas non plus tomber dans l'excès qui est souvent a l'origine de complexité resultant sur l'effet inverse souhaité: projet inmaintenable car architecture pas assez pragmatique (en partant du principe qu'il est livré dans les délais).

Un argument supplementaire à ne pas systématiquement utiliser de DAO spécifique (et donc utiliser l'entity manager directement dans la couche service): Une utilisation simplifié des transaction au niveau de la couche de service (car c'est leur place), plutot que dans la couche de DAO: on peut alors presque mettre Spring à la poubelle (pour la gestion des transactions tout du moins).

Il faut bien être conscient que peu de développeur Java ont suffisament de recul pour utiliser à bon escient struts ou jsf, ou meme jsp et servlet directement avec spring+jpa ou hibernate convanblement.... Les audits que j'ai eu l'occasion de faire sur ce type de projet étaient souvent catastrophique...

D'ailleurs pour ceux qui font du spring + Jpa, je ne peux que vous inviter à regarder la spec ejb3 dans son intégralité: la démarcation des transactions est le job des ejb session et la version 3 de ces composants est au moins aussi simple (voire plus) que ce que propose spring pour répondre au même problème !

mon rêve: après la "fusion" entre ejb entité et hibernate, une fusion "ejb session"/Spring

Sur mon projet actuel, on pourrait concretement supprimer cette couche DAO. Ca part du constat que dans notre cas, il n'y a pas de changement du support de persistence, la seule grande revolution de ce cote la, ca a ete une montee de version du sgbd.

[benwit]

Bonjour.
En y allant à ta façon, c'est vrai su'on utilise JPA-QL qui est Objet et indépendant de la base de données. Toutefois, tu lies ta couche Services irrémediablement à un API de persistance spécifique (JPA) et tu ne pourras pas les réutiliser dans un autre projet avec JDBC/Spring JDBC/Toplink/Hibernate/JDO/etc. comme couche de persistance d'où la nécessité de l'abstraction offerte par la couche DAO.

Un truc doit m'échapper ...

Dans le cas où on utilise une couche de DAO, certes, on pourra réutiliser la couche Service. Mais pour utiliser une autre API de persistence (JDO, ...), il faudra disposer également d'une implémentation des DAO pour cette autre API, n'est ce pas ?

Or, dans l'exemple proposé par Denis où l'on se passe des DAO, n'est t'il pas plus simple de constater qu'il suffit de faire une autre implémentation du service pour la nouvelle API ?

1° CAS (avec DAO) :

Extrait de "ServiceImpl extends Service":

Code :

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

1
2
3
public List<Client> rechercheClientParVille(String ville) {
  return ClientDAO.listeClientParVille(ville);
}

Le service est certes indépendant de l'implémentation de la persistance mais il faut bien une implémentation de ClientDAO pour JPA, JDO, ... ?
Et ceci, pour chaque DAO !


2° CAS (sans DAO) :

Extrait de "JPAService implements Service" :

Code :

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

1
2
public List<Client> rechercheClientParVille(String ville) {
  return entityManager.createQuery("From Client c where c.ville=:ville").setParamater("ville",ville).list()

Il ne faut plus que fournir une autre implémentation du Service (JDOService) ?

Et s'il y a du code commun à JDOService et JPAService, il suffit qu'il étendent un AbstractService ...