+ Répondre à la discussion
Affichage des résultats 1 à 11 sur 11
  1. #1
    Membre habitué
    Inscrit en
    juillet 2007
    Messages
    433
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 433
    Points : 102
    Points
    102

    Par défaut [DAO] Quel code dans les objets métier ?

    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 ?

  2. #2
    Membre éprouvé
    Femme Profil pro
    Développeur Java
    Inscrit en
    décembre 2009
    Messages
    237
    Détails du profil
    Informations personnelles :
    Sexe : Femme

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2009
    Messages : 237
    Points : 484
    Points
    484

    Par défaut

    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

  3. #3
    Membre habitué
    Inscrit en
    juillet 2007
    Messages
    433
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 433
    Points : 102
    Points
    102

    Par défaut

    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 =)

  4. #4
    Membre éclairé Avatar de Mandraxx
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2011
    Messages
    173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Gers (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2011
    Messages : 173
    Points : 356
    Points
    356

    Par défaut

    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.

    @+

  5. #5
    Membre habitué
    Inscrit en
    juillet 2007
    Messages
    433
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 433
    Points : 102
    Points
    102

    Par défaut

    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 ?

  6. #6
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    299
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 299
    Points : 879
    Points
    879

    Par défaut

    Citation Envoyé par Gaetch Voir le message
    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.

  7. #7
    Membre habitué
    Inscrit en
    juillet 2007
    Messages
    433
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 433
    Points : 102
    Points
    102

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    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 :

  8. #8
    Membre éclairé Avatar de Mandraxx
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2011
    Messages
    173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Gers (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2011
    Messages : 173
    Points : 356
    Points
    356

    Par défaut

    Citation Envoyé par Gaetch Voir le message
    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 .

    @+

  9. #9
    Membre Expert

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    novembre 2006
    Messages
    1 247
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 247
    Points : 1 813
    Points
    1 813

    Par défaut

    Citation Envoyé par Gaetch Voir le message
    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.

  10. #10
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    299
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 299
    Points : 879
    Points
    879

    Par défaut

    Citation Envoyé par Tommy31 Voir le message
    Citation Envoyé par Gaetch Voir le message
    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.

  11. #11
    Membre habitué
    Inscrit en
    juillet 2007
    Messages
    433
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 433
    Points : 102
    Points
    102

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •