IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres Discussion :

Avis sur les méthodes dans un DAO


Sujet :

Autres

  1. #1
    Membre régulier
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2010
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2010
    Messages : 42
    Points : 102
    Points
    102
    Par défaut Avis sur les méthodes dans un DAO
    Bonjour,

    Je poste cette question pour trancher une discussion que j'ai avec mes collègues sur les méthodes et donc le rôle d'une classe DAO.
    Tout d'abord un point pour parler des mêmes choses. Une classe DAO, dans la couche DAO, permet à la couche métier de fournir un accès au données, qui sont stockés généralement dans une BD. On trouve les méthodes classiques CRUD(créer, rechercher, MAJ, effacer). Et voici un exemple : une classe modèle User qui contient les informations suivantes :
    - User(identité, login, date de création, date de dernière connexion, boolean:désactivé, etc.. )
    - une classe UserDAO(create, update, delete, retrieve) qui accède à la classe précédente.

    Dans notre conception, nous avons besoin d'informations concernant les utilisateurs comme par exemple :
    1) compter le nombre d'utilisateur
    2) la dernière date de connexion pour un utilisateur
    3) le nombre d'utilisateurs désactivés
    4) la liste des utilisateur dont l'identité commence par une lettre donnée
    5) le temps écoulé depuis la date actuelle et la date de dernière connexion
    6) le nombre d'utilisateur créé pendant une année donnée
    7) le nombre d'utilisateur crée pendant une période donnée

    Maintenant le problème : certains collègues soutiennent que les méthodes permettant de réaliser les points 1 à 5 ne sont pas du ressort de UserDAO, qu'un DAO doit contenir que les méthodes CRUD et à la limite une méthode count() et qu'il faut faire une classe séparée de genre UserStatistiques mais toujours dans la couche DAO
    D'autre soutiennent que ces méthodes relèvent d'une classe UserDAO, sauf peut être la 5 qui serait du métier en récupérant par le UserDAO la date de dernière connexion, la couche métier réalisant le calcul avec la date actuelle.

    Qu'en pensez vous ?
    Merci beaucoup pour vos avis

  2. #2
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 353
    Points
    17 353
    Billets dans le blog
    2
    Par défaut
    la 2 dépend de l'utilsateur, les autres non..

    Donc 2 doit être dans UserDAO..

    Le reste à mon avis non... C'est de l'administration.. Donc je penche très fortement pour la deuxième solution, en modifiant 2 pour le passer dans UserDAO..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  3. #3
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    17 558
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 17 558
    Points : 30 295
    Points
    30 295
    Par défaut
    Salut,

    Le DAO est l'interface/adapteur entre fonctions "business" et "données persistantes" externes.
    => Le DAO "réalise" l'ensemble des opérations qui touche "l'entité" persistante,
    => Ca ne se réduit pas aux opérations CRUD.

    Cette rigueur est "louable" côté maintenabilité, gestion des dépendances: changez le schéma de "User", le DAO vous permettra de savoir quelles sont les méthodes impactées.

    De mon point de vue le soucis n'est pas tant côté pureté de l'utilisation du pattern mais que les opérations liées à une "table" User soient utilisées dans des "business" très différents :
    • l'application au sens session utilisateur,
    • des statistiques sur les utilisateurs de l'application.

    A chaque discussion sur l'un ou l'autre des sujets, la dépendance sur DAO User se transforme en "collision" et rend difficile de faire la part des choses et d'avancer.

    Démêlez (au moins temporairement) les points de vues!
    Les statistiques pouvant être "construites" à partir d'une copie plus ou moins fraîche de la table "User"... Ne pourrions nous pas poser: chaque "business" a "sa" table et donc son DAO?

    Lorsque vous saurez mieux le contour des deux fonctions vous pourrez "arbitrer" plus sainement entre:
    . supprimer la 'copie' et réunir les deux DAO,
    . garder la 'copie',
    . construire un ensemble de tables pour les "statistiques" alimentées par des jobs remontant toutes les heures un agrégat de l'état de la table utilisateurs (datetime, #count, #active, #disabled,...)
    Cordialement

    -W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2010
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2010
    Messages : 42
    Points : 102
    Points
    102
    Par défaut Commentaires sur vos réponses
    Merci pour vos réponses, souviron34 et wiztrick.
    Pour reprendre ce que vous avez écrit et voir si j'ai bien compris
    - Pour souviron34, Les méthodes qui relèvent d'un DAO devrait prendre généralement en argument la classe persistée : create(User), update(User), delete(User), retrieve(User) et le 2: lastDateConnexion(User) par exemple
    Le reste des méthodes concernent de l'administration ou des statistiques.

    - pour wiztrick, le DAO réalise les opérations qui touche l'entité persisté User, donc on pourrait introduire d'autres méthodes dans le DAO comme par exemple la méthode count.

    Je suis d'accord avec vous, les informations demandés mélangent 2 aspects : accès à la classe User(CRUD) et stats sur les Users.
    On pourrait donc imaginer avoir dans la couche business 2 services
    UserManager : qui propose les opérations CRUD sur un User via UserDAO
    UserStats : qui propose, par exemple, des opérations de stats sur les Users et dans laquelle on peut rajouter des opérations sans toucher le UserDAO:
    1: count():int ( qui pourrait être dans le userDAO cependant car c'est vraiment une opération générique)
    3: countDesactivedUser():int
    4: findUserWithInitial(String letter):List<User>
    5: getIntervalDate(Date currentDate, User user):Interval
    6: countUserCreateInPeriod(Date date1,Date date2):int
    Cette classe de service fait appel à une classe de la couche DAO qui pourrait être UserStatsDAO et qui fait les requêtes SQL adéquates dans l'implémentation, si besoin.

    Cette solution sépare, à mon avis, clairement les responsabilités de chacune des classes business et aussi dans la couche DAO.
    Après, pour reprendre ce qu'avance wiztrick, pour la réalisation technique, on peut choisir par exemple de prendre une table de stats réalisé à partir de la table User ou alors réaliser les opérations de stats directement sur la table User, le choix étant guidé, je penses, par la volumétrie, les temps d'accès et le nombre d'accès etc.

  5. #5
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 353
    Points
    17 353
    Billets dans le blog
    2
    Par défaut
    Je ne suis pas du tout spécialiste des modèles et des trucs comme DAO, ni des BDD, mais je me permet de noter que (ce que j'essaye de dire souvent à propos des méthodes et modèles), le "framework" mental associé apporte des biais plutôt qu'il n'aide à clarifier la pensée...

    Comme je ne suis pas spécialiste, je ne me mêlerais pas de la partie conception en termes de BDD ou en termes des modèles utilisés.

    Cependant je voudrais noter que :


    Citation Envoyé par StefGac Voir le message
    Je suis d'accord avec vous, les informations demandés mélangent 2 aspects : accès à la classe User(CRUD) et stats sur les Users.
    Je ne vois pas des "aspects"...

    Je vois :

    a) des propriétés ou paramètres appartenant ou non à une entité
    b) des fonctionalités demandées sur chacune des entités

    Je vois donc :

    • 2 ensembles de fonctionalités distincts :


      • des fonctionalités sur la gestion d'UN utilisateur

      • des fonctionalités sur des statistiques de l'ensemble




    • 2 ensembles de paramètres :


      • un ensemble de paramètres liés à l'usager et seulement à lui

      • un ensemble de paramètres liés aux statistiques qu'on peut faire sur l'ensemble des usagers



    Alors c'est peut-être juste une question de vocabulaire, mais j'ai cependant nettement l'impression que les "frameworks" assoicés aux modélisations ou méthodes perturbent un tant soit peu la simple réflexion...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  6. #6
    Membre régulier
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2010
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2010
    Messages : 42
    Points : 102
    Points
    102
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Je ne suis pas du tout spécialiste des modèles et des trucs comme DAO, ni des BDD, mais je me permet de noter que (ce que j'essaye de dire souvent à propos des méthodes et modèles), le "framework" mental associé apporte des biais plutôt qu'il n'aide à clarifier la pensée...

    Comme je ne suis pas spécialiste, je ne me mêlerais pas de la partie conception en termes de BDD ou en termes des modèles utilisés.

    Cependant je voudrais noter que :




    Je ne vois pas des "aspects"...

    Je vois :

    a) des propriétés ou paramètres appartenant ou non à une entité
    b) des fonctionalités demandées sur chacune des entités

    Je vois donc :

    • 2 ensembles de fonctionalités distincts :


      • des fonctionalités sur la gestion d'UN utilisateur

      • des fonctionalités sur des statistiques de l'ensemble




    • 2 ensembles de paramètres :


      • un ensemble de paramètres liés à l'usager et seulement à lui

      • un ensemble de paramètres liés aux statistiques qu'on peut faire sur l'ensemble des usagers



    Alors c'est peut-être juste une question de vocabulaire, mais j'ai cependant nettement l'impression que les "frameworks" assoicés aux modélisations ou méthodes perturbent un tant soit peu la simple réflexion...
    Tout d'abord, merci pour ces précisions. Elles me permettent de mieux comprendre vos propos. Le classement par fonctionnalités et par paramètres que vous proposez m'intéresse. Pour reprendre votre classement
    • Fonctionnalité concernant l'utilisateur seul.(CRUD compris)
      5: getIntervalDate(Date currentDate, User user):Interval

    • Fonctionnalités sur l'ensemble des utilisateurs )
      1: count():int
      3: countDesactivedUser():int
      4: findUserWithInitial(String letter):List<User>
      6: countUserCreateInPeriod(Date date1,Date date2):int

    • Liste des paramètres concernant l'usager
      User, Date currentDate

    • Liste des paramètres concernant les stats
      String letter, Date date1 & date2

    Ai je bien compris vos propos ?

  7. #7
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 63
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 353
    Points
    17 353
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par StefGac Voir le message
    Ai je bien compris vos propos ?
    hum.... bof.. un peu

    Pour moi, par rapport à votre post initial :

    paramètres usager :

    identité
    login
    date de création
    date de dernière connexion
    boolean:désactivé,
    etc..


    paramètres statistiques :

    nombre d'utilisateurs
    nombre d'utilisateurs désactivés
    temps écoulé depuis la date actuelle et la date de dernière connexion (peu importe l'usager)
    nombre d'utilisateurs crées pendant une période donnée



    fonctionalités liées seulement à l'utilisateur :

    CRUD
    get any paramètre utilisateur


    fonctionalités liées à l'ensemble :

    obtenir le nombre d'utilisateurs
    obtenir le nombre d'utilisateurs désactivés
    obtenir le temps écoulé depuis la date actuelle et la date de dernière connexion (peu importe l'usager)
    obtenir le nombre d'utilisateurs crées pendant une période donnée

    sous-fonctionalités liées au chapitre statistique :

    findUserWithInitial(String letter):List<User>
    définir une date de début de période
    définir une période


    Ces 3 sous-fonctionalités étant, suivant votre cahier des charges, à effectuer systématiquement avant d'appeler les fonctionalités statistiques ou pouvant simplement être éventuellement appelées ponctuellement avant l'une ou l'autre..


    Mais, je le répète, je ne suis en rien connaissant dans le domaine de la modélisation et des BD..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  8. #8
    Membre chevronné

    Homme Profil pro
    Architecte logiciel
    Inscrit en
    novembre 2006
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 252
    Points : 1 904
    Points
    1 904
    Par défaut
    Citation Envoyé par StefGac Voir le message
    Dans notre conception, nous avons besoin d'informations concernant les utilisateurs comme par exemple :
    1) compter le nombre d'utilisateur
    2) la dernière date de connexion pour un utilisateur
    3) le nombre d'utilisateurs désactivés
    4) la liste des utilisateur dont l'identité commence par une lettre donnée
    5) le temps écoulé depuis la date actuelle et la date de dernière connexion
    6) le nombre d'utilisateur créé pendant une année donnée
    7) le nombre d'utilisateur crée pendant une période donnée
    1) DAO. le count() est une fonctionnalité indistinctement applicable à toute entité persisté, elle a donc tout à fait sa place dans un DAO. Il n'est pas interdit de la répercuter sur la couche service.
    2) C'est une propriété de l'entité utilisateur
    3) Fonctionnalité qui revêt un sens métier donc couche service. Charge au DAO d'offrir à cette couche les mécanismes (génériques) de recherche appropriés (le R du CRUD).
    4) Même remarque que 3.
    5) Propriété dérivée de l'entité utilisateur
    6) Même remarque que 3
    7) Même remarque que 3

  9. #9
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par Tommy31 Voir le message
    1) DAO. le count() est une fonctionnalité indistinctement applicable à toute entité persisté, elle a donc tout à fait sa place dans un DAO. Il n'est pas interdit de la répercuter sur la couche service.
    2) C'est une propriété de l'entité utilisateur
    3) Fonctionnalité qui revêt un sens métier donc couche service. Charge au DAO d'offrir à cette couche les mécanismes (génériques) de recherche appropriés (le R du CRUD).
    4) Même remarque que 3.
    5) Propriété dérivée de l'entité utilisateur
    6) Même remarque que 3
    7) Même remarque que 3
    Tout pareil sauf 3), 4), 6) et 7) qui sont discutables. Typiquement cela pourrait être mis dans des méthodes FindUsersBy(...) du DAO plutôt que dans un service.

    Sinon ça veut dire qu'on a qu'une seule implémentation générique du DAO qui ne contient que des méthodes valables pour tous les objets métiers...

Discussions similaires

  1. Donnez votre avis sur les articles de Developpez.com
    Par Geronimo dans le forum C++Builder
    Réponses: 13
    Dernier message: 14/01/2007, 22h00
  2. Donnez votre avis sur les articles de Developpez
    Par Anomaly dans le forum Contribuez
    Réponses: 37
    Dernier message: 29/05/2006, 21h48
  3. Vos avis sur les Blog's SVP
    Par Marc Lussac dans le forum Evolutions du club
    Réponses: 9
    Dernier message: 16/02/2005, 15h21
  4. Votre avis sur les Logos Nouveau / MAJ, Actualisé, etc...
    Par Marc Lussac dans le forum Evolutions du club
    Réponses: 32
    Dernier message: 11/09/2004, 01h17
  5. Problem avec les *.AVI sur les panels
    Par NaDiA_SoFt dans le forum C++Builder
    Réponses: 3
    Dernier message: 31/08/2003, 22h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo