Discussion :

[Gaetch]

Bonjour,

j'ai une question bête sur le pattern Data Access Objects, j'ai bien compris le principe, je sais ce qu'on doit mettre dans les objets DAO. Par contre je ne sais pas comment faire appel à ces objets depuis les objets métier, quel est le code à utiliser ? Par exemple dans MonObjet.créer(), dois-je instancier un MonObjetDAO puis lancer MonObjetDAO.insert() puis détruire l'instance de MonObjetDAO par exemple ?

[Malinaka]

bonjour,
Pour autant que je comprenne ta question, oui tu instancie ton DAO dans ta classe metier . Pour faire simple chaque couche interagit uniquement avec ses couches adjacentes: DB <-> DAO<->Classe metier<->Autres couches

[Gaetch]

D'accord merci j'ai trouvé des exemples de code mais ça ne présente que le code des classes DAO donc j'étais pas sûr. Merci à toi =)

[Mandraxx]

Bonjour,

Perso, je te conseille d'intégrer une couche Factory : ça complexifie l'interaction car tu dois découpler tes DAO en Contrat/Servant mais ça te permet d'intégrer facilement des systèmes de cache, de mesure de perfs et tout ce à quoi je ne pense pas entre ta couche métier et ton data access.

@+

[Gaetch]

Je suis déjà entrain d'intégrer une couche factory pour rendre mon code indépendant du SGBD. Par contre je n'ai pas compris ce que signifie "Contrat/Servant" tu peux m'expliquer ?

[Luckyluke34]

Par exemple dans MonObjet.créer(), dois-je instancier un MonObjetDAO puis lancer MonObjetDAO.insert()

J'aurais tendance à dire qu'un objet métier ne devrait pas explicitement déclencher sa persistance lui-même. Ce n'est pas de sa responsabilité. En général, ce sont d'autres objets qui le font, des objets qui connaissent le contexte d'exécution de l'application et savent si c'est le bon moment pour persister.
Il faut bien distinguer l'instanciation d'un objet de sa persistance. On peut vouloir créer sans pour autant persister.

DAO est issu des core patterns J2EE, jette un oeil ici, il y a tout ce qu'il faut comme exemples de DAO + DAOFactory.

[Gaetch]

J'aurais tendance à dire qu'un objet métier ne devrait pas explicitement déclencher sa persistance lui-même. Ce n'est pas de sa responsabilité. En général, ce sont d'autres objets qui le font, des objets qui connaissent le contexte d'exécution de l'application et savent si c'est le bon moment pour persister.
Il faut bien distinguer l'instanciation d'un objet de sa persistance. On peut vouloir créer sans pour autant persister.

DAO est issu des core patterns J2EE, jette un oeil ici, il y a tout ce qu'il faut comme exemples de DAO + DAOFactory.

Bin justement, sur le premier schéma (j'ai pas encore tout lu) on voit bien que c'est le BusinessObject qui crée l'objet DAO :

[Mandraxx]

Je suis déjà entrain d'intégrer une couche factory pour rendre mon code indépendant du SGBD. Par contre je n'ai pas compris ce que signifie "Contrat/Servant" tu peux m'expliquer ?

Bonjour,

J'ai répondu sans jeter un oeil dans la bible des DP donc mon vocabulaire est peut-être un peu has been

Quand tu fais une Factory, tu as un contrat qui est connu de ta couche métier (interface ou classe virtuelle pure, ça dépend des langages) et un servant qui est complètement masqué (objet concret) dont la classe hérite ou implante le contrat.

Par suite, ta classe Factory propose des méthodes dont les signatures retournent le type statique contrat et dont le corps instancient des objets dont le type dynamique est l'objet servant (concret donc, le "vrai" DAO).

L'appelant métier déclenche donc les traitements du DAO par polymorphisme : ce mécanisme très puissant te permet de modifier le comportement des DAO par adjonction d'une couche supplémentaire si besoin (grâce au pattern Proxy) ou bien de modifier l'implantation des DAO par paramétrage de la Factory. C'est très utile par exemple si tu veux supporter deux types de persistance (SGBD et NoSQL par exemple...).

En espérant avoir été plus clair .

@+

[Tommy31]

Bin justement, sur le premier schéma (j'ai pas encore tout lu) on voit bien que c'est le BusinessObject qui crée l'objet DAO :

Pas lu dans le détail, mais je serais tenté de dire que ce business objet est plutôt ce que l'on a coutume d'appeler aujourd'hui un service.

Un service accède à une entité persisté (Entity) au travers d'un DAO.

[Luckyluke34]

Bin justement, sur le premier schéma (j'ai pas encore tout lu) on voit bien que c'est le BusinessObject qui crée l'objet DAO :

Pas lu dans le détail, mais je serais tenté de dire que ce business objet est plutôt ce que l'on a coutume d'appeler aujourd'hui un service.

Un service accède à une entité persisté (Entity) au travers d'un DAO.

En effet, c'est assez trompeur, BusinessObject dans le schéma ne représente pas l'objet métier persisté par le DAO mais le code client utilisateur du DAO.

"The BusinessObject represents the data client. It is the object that requires access to the data source to obtain and store data. A BusinessObject may be implemented as a session bean, entity bean, or some other Java object, in addition to a servlet or helper bean that accesses the data source."

Donc ça peut être un service mais aussi à peu près n'importe quoi d'autre. On a un exemple avec le code 9.6 dans le lien.

[Gaetch]

Bon j'ai pas compris l'objet Business mais soit les codes pour enregistrer et tout c'est que dans les objets DAO et pas dans les objets métier pourquoi pas.