Quelle architecture autour d'un DAO (type Hibernate) ?

Bonjour à tous,

J'ai une question d'architecture autour de l'utilisation de beans (de
données), d'un DAO (type DAO pour Hibernate), etc ....

Avant de me lancer dans des explications pour poser ma question,
j'aimerai d'abord savoir s'il y a ici des personnes qui travaillent
avec ces technologies ?

Merci

Xavier

Euh... oui. Mais le plus facile c'est de poser la question, et si
quelqu'un passe et peut répondre (même partiellement), il le fait.
La formulation de la question ne sera de toutes façons pas perdue :
ça vous permet de bien définir votre problème et de la poster sur
des forums si vous n'obtenez pas de réponse ici par exemple.

zaz wrote:

Bonjour à tous,

J'ai une question d'architecture autour de l'utilisation de beans (de
données), d'un DAO (type DAO pour Hibernate), etc ....

Avant de me lancer dans des explications pour poser ma question,
j'aimerai d'abord savoir s'il y a ici des personnes qui travaillent
avec ces technologies ?

Merci

Xavier

Ptet ben qu'oui, ptet ben qu'non ;-)
(question de normand, réponse de normand)

A+ [pour une vrai question ;-) ]
TM

Salut à tous,

Bon effectivement, désolé pour la "non-question" ...

C'est pas facile à expliquer simplement, je vais essayer. Dans un
structure "bien faite", les données sont dans le "bean" qui ne fait
que contenir des attributes et des accesseurs set et get. Un DAO est
capable de faire le lien avec une base de données pour la persistance
(via Hibernate par exemple), il est capable de stocker chaque bean
dans la base, les mettres à jour, les supprimer, et les récupérer bie n
sûr !

Question : lorsqu'une valeur du bean change, qui s'occupe de
déclencher la mise à jour vers la base ? :
- le bean lui-même, dans sa méthode "set", mais il doit alors
connaitre son DAO et ça ne me semble pas propre du tout ...
- le DAO qui connait alors tous les bean, mais faut alors qu'il soit
en "audition" dessus, donc faut ajouter cette fonctionnalité au beau
(ajout de listener, notifications à chaque set, ...)
- un autre objet, un "manager" (bon nom ?), mais alors tout changement
à apporter au bean doit passer par lui, et là, c'est pas trop
pratique, c'est tellement plus simple de partout dans l'appli de faire
"set" sur le bean

Quels sont vos avis ?

Merci

Xavier

> Salut à tous,

Bon effectivement, désolé pour la "non-question" ...

C'est pas facile à expliquer simplement, je vais essayer. Dans un
structure "bien faite", les données sont dans le "bean" qui ne fait
que contenir des attributes et des accesseurs set et get. Un DAO est
capable de faire le lien avec une base de données pour la persistance
(via Hibernate par exemple), il est capable de stocker chaque bean
dans la base, les mettres à jour, les supprimer, et les récupérer bien
sûr !

Question : lorsqu'une valeur du bean change, qui s'occupe de
déclencher la mise à jour vers la base ? :
- le bean lui-même, dans sa méthode "set", mais il doit alors
connaitre son DAO et ça ne me semble pas propre du tout ...
- le DAO qui connait alors tous les bean, mais faut alors qu'il soit
en "audition" dessus, donc faut ajouter cette fonctionnalité au beau
(ajout de listener, notifications à chaque set, ...)
- un autre objet, un "manager" (bon nom ?), mais alors tout changement
à apporter au bean doit passer par lui, et là, c'est pas trop
pratique, c'est tellement plus simple de partout dans l'appli de faire
"set" sur le bean

Quels sont vos avis ?

Merci

Xavier

Bonjour,

en fait, il ne faut pas mélanger l'état d'un bean et sa persistence en
base de donnée.
- Un bean n'a pas à s'occuper de s'enregistrer en base de donnée, ce
n'est pas son rôle. Il définit juste des méthodes publiques nécessaires
à changer son état. A toi de décider a quel moment tu souhaites
persister cet état.
- Un dao doit juste être capable de persister un bean, ce n'est surtout
pas lui qui doit décider quand persister les modifications, il n'a pas
à s'occuper d'écouter les modifications du bean.
- La bonne réponse est donc la troisième, un manager doit être chargé
d'enregistrer (ou non) les modifications d'un bean (via les dao).
suivant tout un tas de règles définies par ton application.

De plus techniquement, les pertes de performances seraient très
importantes si a chaque fois que tu modifiais l'attribut d'un bean, ton
programme lancait une requete en base de donnée.
par exemple
<CODE>
setName("toto");
setOld(28);
setSize(180);
</CODE>
nécessiterait 3 requetes en bases de donnée alors que ça peut
simplement etre fait par une seule requete.


C'est pour ça que beaucoup de développeurs utilisent une couche service
ou manager afin de séparer les opérations sur les beans des beans eux
même.
Cette séparation (qui peut paraitre fastidieuse) a beaucoup d'autres
avantages et je te la conseille fortement.

zaz wrote:

J'ai une question d'architecture autour de l'utilisation de beans (de
données), d'un DAO (type DAO pour Hibernate), etc ....

Tapes hibernate dao sur google.
Prends un lien au pif, disons le premier (hibernate.org), il décrit assez
bien le fonctionnement des DAO.

Salut,

C'est pour ça que beaucoup de développeurs utilisent une couche servic e
ou manager afin de séparer les opérations sur les beans des beans eux
même.
Cette séparation (qui peut paraitre fastidieuse) a beaucoup d'autres
avantages et je te la conseille fortement.

Ca m'intéresse, peux-tu m'en dire plus (ou des liens) ?

Merci

Xavier

C'est la session d'hibernate qui te permet de savoir si tu doit mettre
a jour ton bean, si bien sur tu lui dis de la mettre a jour
(saveOrUpdate). Avec le versionning et le dynamicUpdate, tu ne met a
jour que les champs modifiés

C'est la session d'hibernate qui te permet de savoir si tu doit mettre
a jour ton bean, si bien sur tu lui dis de la mettre a jour
(saveOrUpdate). Avec le versionning et le dynamicUpdate, tu ne met a
jour que les champs modifiés