[DAO] Une petite question sur le modèle de conception...

Salut à toutes & à tous.

Je me suis intéresser au design pattern DAO et j'ai lu l'article proposé chez Sun.
Mais comme tout exemple, il n'est pas adapté & ne montre pas les réelles difficultés.

Ainsi je me demandais comment bien utilisé les DAO lorsque le Transfert Object est lié à d'autres objets par des associations?


Faut-il appeller les DAO des ces autres objets, auquel cas (si l'association est doublement naviguable) il faut transmettre un paramètre pour dire que l'autre extremité à déjà été chargée ou sauvée?

J'avoue ne pas voir de solution.
Quelqu'un peut-il m'aider?

Merci d'avance.

en general, les dao ne retournent pas de dto (seulement des objets métiers) sauf si tu as peur aux effets de bords (naviguer vers une association null par exemple)
En général, les dto sont plutot retounés par la couche au dessus (business logic) qui utilise les dao

c une mauvaise idée que d'utiliser les dao entre elles, surtout au niveau optimisation sql
ex: un client et ses commandes
(1) si dans clientdao tu charge le client puis tu charge ses commandes avec daocommandes tu a 2 requetes distinctes
(2) si dans client dao tu utilises les joinures, tu n'a plus qu'une requetes
=> le pb répété sur toutes les associations peut devenir problematique

Avant tout, merci pour les réponses.

en general, les dao ne retournent pas de dto (seulement des objets métiers) sauf si tu as peur aux effets de bords (naviguer vers une association null par exemple)

D'après ce que j'ai lu sur http://java.sun.com/blueprints/corej...essObject.html
les DAO crée les DTO depuis les infos de la couche persistante et les retourne à la couche Buisness.

c une mauvaise idée que d'utiliser les dao entre elles, surtout au niveau optimisation sql

Je suis bien d'accord avec toi.
On garde ton exemple de client et de factures.
Si l'objet métier facture appelle

Code :

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

ClientDAO.sauver( this.getTO() )

où TO est le TranfertObject qui contient des liens vers des factures (aussi TO), il va de soi de ne pas appelle explicitement

Code :

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

FactureDAO.sauver( this.getTO().getFactures().get(i)

pour chaque facture. Encore plus si facture contient des associations vers des objets ligneFactures.

Le problème est le même pour le chargement. Comment charger un client (sans charger tout le graphe d'objet) sachant qu'une fois chargé on aura peut être besoins de ses factures?

Alors comment fait-on?

Donne un exemple de cas pour ton Transfert Object lié à d'autres et montre le résultat que tu veux obtenir au final, ça clarifiera les choses

Je crois que c'est fais dans ce post.

Merci d'avance

Je pense que certaines notions d'architecture te manquent, je vais tacher de te fournir quelques pistes à suivre.

Le pattern DAO est un Data Mapper. Il a la charge de faire le lien entre tes objets métiers (Business Objects) en mémoire et tes instances dans la base de données en fournissant une interface indépendante de la technologie sous-jacente.

Les objets métiers constituent un Domain Model qui va représenter les objets vraiment importants pour ton application (factures, clients, produits) ainsi que leur comportement (ce n'est pas juste des données, écrire du code métier dans ces objets est essentiel pour avoir un domaine riche).

Il est crucial que tes objets métiers n'aient pas de dépendances vis-à-vis de la couche de persistance. En d'autres termes, tes factures ignorent tout de tes DAO !!!

La couche Business dont tu parles se situe "au dessus" de la couche de persitance et du Domain Model. Généralement, on parle de services qui vont coordonner tes actions : charger un client et ces factures avec un DAO, ordonner à un objet métier de faire un calcul à partir des infos en sa possession (calcul du prix d'une commande à partir des lignes de cde associées...).

Pour rendre les associations navigables, ca peut dépendre de la technologie utilisée. Si tu utilises un outil d'ORM (Hibernate, JDO, Toplink), cela est fait automatiquement pour toi. Si tu utilises JDBC, tu peux :
- écrire des DAO qui chargent explicitement les relations,
- écrire des implémentations particulières de tes collections qui utiliseront en arrière plan des DAO pour faire du lazy-loading et sous-classer tes objets métiers pour gérer le lazy-loading en utilisant le pattern Proxy.

La dernière solution (collections et sous-classes à coder) étant bien sur celle qui te donnera le plus de travail.

La pattern DTO est souvent considéré comme un anti-pattern mais peut se montrer très utile pour certains usages.

Meric pour les réponses.

dlemoing je suis d'accord avec tes définiftions.

Cependant

La couche Business dont tu parles se situe "au dessus" de la couche de persitance et du Domain Model.

je ne fais pas de différence entre la couche buissness & le modèle du domaine. J'emploi les 2 termes indifférement.

Par contre quand tu dis

charger un client et ces factures avec un DAO

cela sous entend que c'est le même DAO qui va gérer client & facture. Je ne l'avais pas compris ainsi. Je pensais qu'il y avait un objet DAO (et un TO) par objet Métier.

Si je te suis il peut exister un DAO pour plusieurs objets Métier?
Cependant le problème des associations reste ouvert concernant le chargement & l'enregistrement.
Dois-je charger/enregister tout le graphe d'objet?
Sinon comment limité une profondeur sachant que je ne sais pas à l'avance ce dont je vais avoir besoin.

Concernant la seconde solution, c'est le principe d'hibernate. Mais comme tu l'as dis c'est long à écrire.

Alwin

Le principe est simple, un MAO assure la persistance d'un modèle ou d'un sous ensemble et non plus d'une seule classe.
J'ai, dans mon architecture des notions d'ExternalReference afin de prendre en compte les relations de références et non de compositions

J'ai donc, par exemple, un MAO Facture qui gère mon modèle [Facture] ->* [LigneDetail] et rien ne m'empèche de référencer [Client] [Fournisseur] [Dossier] ou autres entités mais sans être responsable de leur cycle de vie ou modifications.

Je ne connais pas suffisamment Hibernate pour tout comprendre à cce que tu as écrit mais merci quand même.

Cependant je suis sur qu'il existe une solution. Comment faisant-on avant Hibernate??

Envoyé par DarkNagash

je ne fais pas de différence entre la couche buissness & le modèle du domaine. J'emploi les 2 termes indifférement.

Relis mes définitions et essaie de faire la différence, ca devrait t'aider à éclaircir un certain nombre de points.

Envoyé par DarkNagash

Je pensais qu'il y avait un objet DAO (et un TO) par objet Métier.

Oui et non : souvent on utilise un DAO par objet métier mais cela peut également dépendre de la complexité de ton application et des regroupements que tu souhaites faire (commande-ligne de commande dans un seul DAO par exemple). Tout dépend du contexte.

Envoyé par DarkNagash

Cependant le problème des associations reste ouvert concernant le chargement & l'enregistrement.
Dois-je charger/enregister tout le graphe d'objet?
Sinon comment limité une profondeur sachant que je ne sais pas à l'avance ce dont je vais avoir besoin.

La encore tout dépend du contexte. C'est un sujet complexe qu'on appelle Object-Relational Impedance Mismatch (cherche sur Google). Hibernate propose une solution à ce problème.
Si tu veux résoudre le problème, il va falloir soit utiliser un outil, soit coder une solution "relativement complexe". Si tu souhaites te lancer dans l'aventure lit ce livre.

Plus sérieusement, tu devrais te résoudre à ne pas chercher une solution totalement transparante. L'implémentation de ton DAO devra te fournir des méthodes qui se chargeront de charger les relations en même temps que ton objet selon une profondeur définit à l'avance. Par exemple, pourquoi ne pas utiliser une méthode pour charger une facture et une autre pour charger une facture et les associations de celle-ci. C'est moins "transparant" mais même avec hibernate ca te permet un meilleur contrôle des requetes si tu sais que tu auras besoin des infos contenues dans les associations et que tu veux éviter le lazy-loading.

D'après ce que j'ai lu sur http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
les DAO crée les DTO depuis les infos de la couche persistante et les retourne à la couche Buisness.

c pas interdit! mais du coup du te retrouves avec un domaine (trop?) riche a granularité tres fine, ettu t'exposes a encapsuler des dto enter eux...

Le pattern DAO est un Data Mapper. Il a la charge de faire le lien entre tes objets métiers (Business Objects) en mémoire et tes instances dans la base de données en fournissant une interface indépendante de la technologie sous-jacente.

Les objets métiers constituent un Domain Model qui va représenter les objets vraiment importants pour ton application (factures, clients, produits) ainsi que leur comportement (ce n'est pas juste des données, écrire du code métier dans ces objets est essentiel pour avoir un domaine riche).

-> entierement d'accord
toutefois est ce que dans la pratique on ne mélange pas les 2 patterns, du genre un DAO pour les objets métiers imporants, les autres tables à mapper n'ayant pas toujours besoins d'une dao?

Envoyé par mauvais_karma

c pas interdit! mais du coup du te retrouves avec un domaine (trop?) riche a granularité tres fine, ettu t'exposes a encapsuler des dto enter eux...

Les DTO sont à éviter sauf s'ils peuvent être justifiés (cf le lien que j'ai donné).

Envoyé par mauvais_karma

-> entierement d'accord
toutefois est ce que dans la pratique on ne mélange pas les 2 patterns, du genre un DAO pour les objets métiers imporants, les autres tables à mapper n'ayant pas toujours besoins d'une dao?

J'ai répondu à la question quand je parlais des associations qu'on pouvait faire : DAO unique pour un couple commande/ligne de commande ou dans un cas général objet/type d'objet (type d'objet étant une table de référence). Bien sur il n'est pas nécessaire d'avoir un DAO par objet métier (notamment pour le cas de tables de références).

Un exemple simple :
J'ai une table OBJET et une table TYPE_OBJET (avec respectivement les classes Objet et TypeObjet), avec une relation entre les 2. Je peux très bien avoir un seul DAO ObjetDAO qui s'occupera de gérer les objets Objet et TypeObjet.

Code :

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

1
2
3
4
5
6
7
8
9
public interface ObjetDAO() {
    public void saveObjet(Objet obj);
    public void deleteObjet(Objet obj);
    public Objet getObjetById(Long id);
    ...
    public void saveTypeObjet(TypeObjet typObj);
    public void deleteTypeObjet(TypeObjet typObj);
    ...
}

dlemoing, je vois dans ton exemple de ObjetDAO, les méthodes saveTypeobject(), deleteTypeobjet(). Je vois pas la différence avec le cas où tu as une classe TypeObjetDAO à part? Et qui c'est qui va appeler ces méthodes?

Envoyé par trungsi

Je vois pas la différence avec le cas où tu as une classe TypeObjetDAO à part? Et qui c'est qui va appeler ces méthodes?

Ca ne fait pas une grande différence, mais je rappelle que je répondais à une question : doit il y avoir un DAO par objet métier ? Et la réponse est : pas obligatoirement. On est libre de faire comme dans mon exemple si on le souhaite.
Dans le cas que je présentais, il n'est pas forcement nécessaire d'avoir un objet DAO pour tous les objets métiers et notamment dans le cas des tables de références.
La notion de TypeObjet étant très étroitement lié à celle d'Objet, on peut éventuellement faire un regroupement dans ce cas...rien ne l'empeche mais ce n'est absolument pas une obligation.
De même, prends le cas de petclinic dans les exemples de Spring et tu verras qu'on utilise un seul DAO pour toute l'application et elle n'est pas plus mal écrite pour autant.
Il n'y a pas une seule et unique réponse, tout dépend du contexte et du design que l'on souhaite donner à l'application.

Merci pour ta participation dans ce topic

Envoyé par dlemoing

doit il y avoir un DAO par objet métier ? Et la réponse est : pas obligatoirement. On est libre de faire comme dans mon exemple si on le souhaite.

J'ai compris que le regroupement de la persistance de deux objets au sein d'un même objet DAO dépend du contexte de leur corrélation entre eux. C'est donc une affaire de feeling & de dependance entre les 2 objets métiers.

Envoyé par trungsi

c pas interdit! mais du coup du te retrouves avec un domaine (trop?) riche a granularité tres fine, ettu t'exposes a encapsuler des dto enter eux...

Tout a fait. J'ai des TO qui ont des associations vers d'autres TO. Ce n'est pas la bonne manière de procédé? Si c'est le cas je n'ai rien compris à l'article de Sun.
Par contre mes classes du domaine ne possède aucunes association entre elles. Elles encapsulent les TO et offrent des méthodes métiers par rapport à mes TO qui son de simples beans.

Mais j'avoue que dès que je dois sauver un TO qui possède des références vers d'autres, c'est le bordel.
D'où le topic.

Envoyé par dlemoing

Plus sérieusement, tu devrais te résoudre à ne pas chercher une solution totalement transparante. L'implémentation de ton DAO devra te fournir des méthodes qui se chargeront de charger les relations en même temps que ton objet selon une profondeur définit à l'avance.

Merci pour l'explication. Elle me conforte dans mon idée comme quoi il faut determiner à l'avance les données dont on aura besoin.
Par contre dans le code, si j'ai besoin des factures d'un client et que je ne les ai pas chargée il faut d'abord tester si la liste des factures est null ou non puis appelle la bonne méthode du DAO et enfin accéder aux factures. Comme tu l'as dis ce n'est pas transparent du tout, mais si c'est la seule solution.
De plus ce code peut être contenu dans le code du TO de client. (Comme suggérer par dlemoing)

Un dernier problème se pose alors. C'est la manière de décharger les informations inutiles lorsque le graphe d'objet est trop lourd, surtout lors d'application multi utilisateur

Donc, je reformule ma question. Comment peut on décider qu'une classe du domaine modèle doit avoir une classe DAO ou pas? Est ce que c'est vraiment dépedant de chaque context, chaque situation ou y a t-il des principles à appliquer?

Merci de tes éclaircissements

Je vient de lire (brièvement) le code source de JForum, concernant la couche d'accès au données.

Lorsque je regarde les objets TO (forum, topic, liste de message...) je me rend compte que le créateur à denaturé son modèle objet pour le rendre "compatible" avec une base de données. Ainsi les objets ne possèdent quasiment aucune association entre eux. Un objet forum par exemple ne comporte qu'une liste d'identifiant de topic.

Je ne pense que ce type de méthodologie soit la bonne cepandant elle est pratiquée.

Est-ce une méthode à appliquer lorsque l'on crée soi même sa couche d'accès aux données (afin de ne pas réinventer la roue avec Hibernate ou les JDO) sachant que les associations sont un des obstacles de la non conformité Objet/Relationnel (ou autre)?

Envoyé par trungsi

Donc, je reformule ma question. Comment peut on décider qu'une classe du domaine modèle doit avoir une classe DAO ou pas? Est ce que c'est vraiment dépedant de chaque context, chaque situation ou y a t-il des principles à appliquer?

Oui je pense que cela dépend fortement du contexte mais surtout du dégré de liaison entre deux (ou plusieurs objets).

Il me paraît clair qu'une relation de composition est un cas typique de partage d'un DAO.
En fait tu dois t'interroger sur le couplage des différents objets entre eux, d'un point de vue sémantique

N'utilises pas de TO, j'ai l'impression que ca te complique la vie et tant que tu ne peux pas les justifier il faut éviter de les utiliser. De plus, ce n'est pas à ton objet métier de construire le TO mais à un assembleur de TO qui est utilisé par ta couche métier (pas les objets métiers).
Les objets du domain model (objets métiers) doivent avoir des associations entre eux : une commande doit avoir une liste de lignes de commande et à chaque ligne de commande on associe un produit. C'est ces relations entre les objets du domain qui font la force du pattern et de la programation orienté objet.

Par contre dans le code, si j'ai besoin des factures d'un client et que je ne les ai pas chargée il faut d'abord tester si la liste des factures est null ou non puis appelle la bonne méthode du DAO et enfin accéder aux factures.

Tu peux éventuellement prévoir une méthode sur ton DAO qui charge le client avec ses factures si tu sais que tu en auras besoin...non ? Mais effectivement, tu peux commencer par faire un test avant de demander dans ton service de faire le chargement des factures et de "peupler" la collection de factures de l'objet "Client".

Quelques regles à respecter :
- tes objets métiers n'encapsuleront pas de TO,
- tes objets métiers ont des associations entre eux,
- cherche de bons exemples sur le net, par exemple ici,
- pas de DTO !!!!! (sauf si tu peux le justifier)

PS : DTO est souvent considérer comme un anti-pattern !!! A utiliser avec précaution.

Envoyé par trungsi

Donc, je reformule ma question. Comment peut on décider qu'une classe du domaine modèle doit avoir une classe DAO ou pas? Est ce que c'est vraiment dépedant de chaque context, chaque situation ou y a t-il des principles à appliquer?

Merci de tes éclaircissements

Très sincerement, ca dépend de ce que tu veux faire, des contraintes (techniques et fonctionnelles), du temps, de la complexité de l'appli, du respect des normes de codage dans la boite où tu interviens...
Bref, chaque cas est unique.

Envoyé par dlemoing

Quelques regles à respecter :
- tes objets métiers n'encapsuleront pas de TO,
- tes objets métiers ont des associations entre eux,
- cherche de bons exemples sur le net, par exemple ici,
- pas de DTO !!!!! (sauf si tu peux le justifier)

Bon je te remercie pour le temps passé à me répondre et pour les 4 commandements ci-dessus.

J'ai lu l'exemple de petclinic. Il est très simple & parlant. Merci (j'ai d'ailleurs pu constater la rapidité de l'utilisation d'Hibernate pour le developpement.

Je vais m'en inspiré.

Attention, l'exemple que tu as vu bénéficie de l'infrastructure de Spring (support d'hibernate ou de JDBC, support des transactions déclaratives...).
Tu peux faire sans cette infrastructure mais tu devras alors gérer des aspects comme la gestion des transactions de manière programmatique plutot que de facon déclarative.