Discussion :

[StefGac]

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

[souviron34]

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..

[wiztricks]

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

[StefGac]

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.

[souviron34]

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 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...

[StefGac]

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 ?

[souviron34]

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..

[Tommy31]

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

[Luckyluke34]

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...