Question d'Architecture : utilisation d'un Database Access Object

Bonsoir,

Bonjour,

j'ai un objet Questionnaire avec des méthodes genre isFerme, hasReponses
etc...
Pour l'instant, la cnx, le code SQL , le traitement des exceptions est
imbriqué dans les méthodes. => Ca ne me plait pas.

Cela signifie donc que la classe Questionnaire a d'autres
responsabilités que l'accès à la base de données. Il s'agit
probablement du container des données caractérisant le concept
de questionnaire dans l'application. Aussi surprenant que cela
puisse paraître en programmation objet, il vaut effectivement
mieux séparer les traitements des données ...

j'ai donc pensé créer un objet dao qui aurait des "copies" de ces
méthodes et qui renverraient des objets Java. Cet objet cree la cnx,
fait le traitement sql et renvoie un objet.

Question n°1 : puis-je les nommer exactement comme le nom des méthodes
de la classe Questionnaire, (et je fais l'appel à mon objet dao depuis
la classe Questionnaire) ? Est-ce correct ?

En pratique, les services rendus par le DAO sont souvent différents
des services au niveau du concept. Le DAO rends généralement 4
types de services :
- création d'une nouvelle entité
- enregistrement d'une modification d'une entité
- suppression d'une entité
- recherche sur critères d'une ou plusieurs entités
Ces services sont utilisés non pas par le container de données
(la classe questionnaire), mais par un processus de
l'application qui manipule les données.
Les services que tu cites (isFerme, hasResponse) correspondent plutôt
à la lecture de valeurs d'attributs du questionnaire (je fais des
hypothèses à partir des informations que tu as fournies). Le rôle
du DAO sera plutôt de lire en une seule fois tous les attributs
d'une ou plusieurs entités.

Question n°2 : j'ai l'intention de rendre les méthodes de mon objet dao
statiques car je vois pas l'interet de l'instancier pour un simple
isValide par ex : il me renvoie vrai ou faux et après je trashe mon objet.
A moins que j'instancie dao dans le constructeur de Questionnaire et le
définisse en propriété ?
Votre avis ?

Tu peux commencer par des méthodes statiques, quitte à ce que
ultérieurement tu modifies le DAO pour le transformer en fabrique.

Voilà, si vous avez des liens sur le sujet car ce sont des questions
très interessantes (j'ai pas encore lu le pattern dao ;(, alors je viens
vous solliciter et avoir votre retour d'xp surtout)

Les points importants dans le DAO sont les suivants :

1) dans ce que tu décris, tu utilises une connexion JDBC pour lire
un attribut. Dans un traitement donné, tu liras probablement
plusieurs attributs, et c'est mieux si la même transaction est
utilisée (cohérence des infos et performances). Il te faut donc
coder un mécanisme pour faire suivre le contexte transactionnelle.
La méthode la plus simple (bien que peu élégante) consiste à ajoute
un paramètre Connexion à toutes les méthodes des DAO. La méthode
la plus sophistiquée consiste à utiliser un gestionnaire de
transactions (JTA/JTS).

2) attention aux relations : il est évident que tu vas faire une
classe de DAO par classe persistante. Tu recherches par exemple
pour une fonction de l'application une liste de clients et de
factures associées. La manière de procéder la plus évidente est
la suivante : tu demande au DAO des clients de rechercher ceux
qui répondent aux critères, puis pour chaque client, tu demandes
au DAO des factures de te donner la liste des factures du client.
Pour n clients tu fais alors n+1 selects alors que 2 suffisent.
Il est très tentant de rendre transparente la navigation dans
les relations lorsque l'on a des DAO, toutefois il faut toujours
garder à l'esprit les requêtes en base que cela induit.

Merci par avance !

Hope this helps !

Bonjour,
tout d'abord merci pour ta réponse !

Cela signifie donc que la classe Questionnaire a d'autres
responsabilités que l'accès à la base de données. Il s'agit
probablement du container des données caractérisant le concept
de questionnaire dans l'application. Aussi surprenant que cela
puisse paraître en programmation objet, il vaut effectivement
mieux séparer les traitements des données ...
Oui, c'est le découplage métier - Bas niveau sql qui m'interesse.

En pratique, les services rendus par le DAO sont souvent différents
des services au niveau du concept. Le DAO rends généralement 4
types de services :
- création d'une nouvelle entité
- enregistrement d'une modification d'une entité
- suppression d'une entité
- recherche sur critères d'une ou plusieurs entités
Ces services sont utilisés non pas par le container de données
(la classe questionnaire), mais par un processus de
l'application qui manipule les données.
Les services que tu cites (isFerme, hasResponse) correspondent plutôt
à la lecture de valeurs d'attributs du questionnaire (je fais des
hypothèses à partir des informations que tu as fournies). Le rôle
du DAO sera plutôt de lire en une seule fois tous les attributs
d'une ou plusieurs entités.
Tu supposes juste :)

Tu peux commencer par des méthodes statiques, quitte à ce que
ultérieurement tu modifies le DAO pour le transformer en fabrique.
C'est bien ca, ca me plait bien comme idée !

Merci bcp pour ces précisions :

Les points importants dans le DAO sont les suivants :

1) dans ce que tu décris, tu utilises une connexion JDBC pour lire
un attribut. Dans un traitement donné, tu liras probablement
plusieurs attributs, et c'est mieux si la même transaction est
utilisée (cohérence des infos et performances). Il te faut donc
coder un mécanisme pour faire suivre le contexte transactionnelle.
La méthode la plus simple (bien que peu élégante) consiste à ajoute
un paramètre Connexion à toutes les méthodes des DAO. La méthode
la plus sophistiquée consiste à utiliser un gestionnaire de
transactions (JTA/JTS).

2) attention aux relations : il est évident que tu vas faire une
classe de DAO par classe persistante. Tu recherches par exemple
pour une fonction de l'application une liste de clients et de
factures associées. La manière de procéder la plus évidente est
la suivante : tu demande au DAO des clients de rechercher ceux
qui répondent aux critères, puis pour chaque client, tu demandes
au DAO des factures de te donner la liste des factures du client.
Pour n clients tu fais alors n+1 selects alors que 2 suffisent.
Il est très tentant de rendre transparente la navigation dans
les relations lorsque l'on a des DAO, toutefois il faut toujours
garder à l'esprit les requêtes en base que cela induit.
Faut que je creuse la question en effet

Hope this helps !
oui, merci bcp bcp, c'était très bien expliqué :)

Il va définitivement falloir que je me documente sur le sujet plutot que
de rédécouvrir les Design-Patterns :)