Explications de DAO et utilisation au sein d'un MVC.

Bonjour,

voilà, j'ai beau avoir lu et relu des tutoriels, les DAO restent confus dans ma tête. Utiliser une API externe ne m'intéresse pas : c'est comprendre le système dans ses fondements que je souhaite.

Pour faire simple, partons des Beans (Customer, tiens) et mettons que je veux juste un système basé sur une base de données unique (pour l'exemple, PostgreSQL) :

Chaque classe Bean (Customer) doit être liée à une interface (CustomerDAO), qui est implémentée par une classe (PostgreCustomerDAOn liée à un pool de connexion) ? Ou bien CustomerDAO est déjà une implémentation basique et générique qui fait appel à un gestionnaire global des données (PostgreMonApplicationDAO) ?

La différence entre les deux est que le premier cas semble plus souple car chaque CustomerDAO (qui est en fait un PostgreCustomerDAO) se connecte indépendamment à Postgre (j'entends par là : fait ses requêtes, transforme le resultset en bean, etc.), tandis que la seconde permet de réduire considérablement le nombre de classes (2 classes par bean au lieu de 3), mais utilise une classe monstre PostgreMonApplicationDAO qui a l'ensemble des méthodes métier liées à tous les beans. Si c'est encore autre chose, n'hésitez pas à me corriger.

Ensuite, dans une architecture MVC (plutôt Swing que web), le contrôleur a-t-il connaissance du CustomerDAO, ou bien ne travaille-t-il qu'avec les Beans ? J'aurais tendance à penser à la seconde solution, mais cela pose problème pour certains cas, comme la création de nouveaux objets. Le CustomerBean est dans un cas obligé d'être associé à un CustomerDAO, et dans l'autre non.

Enfin, si vous savez répondre à ces quelques questions, ça serait sympa ;) Et si vous avez un lien vers un endroit où il y a plus d'exemples que le petit customer dans son coin, je prends de suite (en fait, au moins deux TransferObjects/Beans).

C'est curieux, les DAO sont vraiment les objets les plus simples à comprendre...

Pour faire simple :

- tu as un POJO qui représente ton enregistrement (Customer par exemple) sous forme d'un objet java simple

- tu as un DAO qui représente les méthodes liées à la vie d'un enregistrement ou à l'extraction d'enregistrements.
On va trouver généralement :
- findById(...)
- save(Customer customer)
- delete(Customer customer)
- update(Customer customer)
- findAll(...)

Il est clair que ton POJO peut être plus ou moins complexe, il peut inclure des listes d'objets sous-jacents ou des objets liés etc...
Par exemple, dans le cas d'une facture, on retrouvera :
- un objet Client
- une liste d'objets LigneFacture
- un objet AdresseFacturation
etc...

Ensuite, il y a la notion de DTO (Data Transfert Object). C'est un sujet assez sensible, certains sont pour, d'autres sont contre.
Globalement, ils servent à transférer des objets structurés en fonction de l'usage final (souvent IHM). On pourrait voir ces objets comme des "vues" spécialisées.
Rien n'empêche d'utiliser les POJOs à cet effet, mais attention avec les EJB et/ou le lazy loading, il peut y avoir des surprises.
L'autre avantage des DTO est de rendre plus indépendant l'application de la structure physique des enregistrements DB

Maintenant, pour le modèle MVC, les DAO sont utilisés au niveau modèle, et les POJOs servent à charger les vues.

J'espère t'avoir éclairci les idées...;)

A+

Tout à fait, tu as bien éclairci.

Mais pas tout à fait quand même, j'y reviens.

La confusion venait du fait que j'ai vu des tutos comme celui de Sun, et que pour mieux comprendre, j'ai cherché sur Google CodeSearch des implémentations de DAO, et j'en ai vu de toute sortes. Puis hier, je me suis mis à plat, j'ai réfléchi à la manière dont moi je voyais la chose et j'obtenais quelque de plus proche du tuto de sun que de ce que j'avais vu via Google, sans y parvenir.

Par contre, tu parles de POJO... Ne vaut-il mieux pas utiliser des Beans (de java.bean, pas de EJB) ? La différence est minime, je sais, mais en tant que Bean (et donc sérialisable), un objet permet d'être transféré et donc de servir de DTO à la fois, non ?

Pour ce qui est encore flou dans ton explication, tu me dis qu'on a (par exemple) Customer et CustomerDAO. Mais l'une de mes questions portait sur CustomerDAO est-il (en règle générale) une classe qui délègue tout à MonApplicationDAO (une autre interface, qu'on implémente par PostgreMonApplicationDAO) comme une façade, ou un proxy ? Ou est-ce une une interface qui est implémentée par PostgreCustomerDAO ? C'est là dessus que je voyais le plus de différence entre les tutos et les implémentations disponibles sur le net.

C'est une couche très basse de l'implémentation, je sais, mais conceptuellement, je bloque sur cette notion.

Bonjour,
Ce sujet a été longuement et fréquemment débattu dans divers forums.
Je te propose l'un des plus récents au cas où tu l'a raté:
:arrow: http://www.developpez.net/forums/sho...d.php?t=447304.

Sinon, une simple recherche avec le terme DAO te donne ceci:

:arrow: http://www.developpez.net/forums/sho...d.php?t=462580
:arrow: http://www.developpez.net/forums/sho...d.php?t=424139
:arrow: http://www.developpez.net/forums/sho...d.php?t=370054
:arrow: http://www.developpez.net/forums/sho...d.php?t=355159
:arrow: http://www.developpez.net/forums/sho...d.php?t=343249

Ca vaut le coup de lire tout ça, qui plus est basé sur les expériences réelles des membres ;)

Oui, je l'ai raté, désolé :? Je ne viens sur developpez que lorsque la charge de travail me le permet...

Et dans mes recherches, j'ai été trop restrictif en ayant plus de mots-clé, ce qui au final ne me laissait qu'un ou deux sujets et qui ne répondaient pas à mes questions. Ou alors ces sujets ne parlaient que de l'utilisation dans le cadre web, qui me désole, puisque je n'ai fait jusqu'à présent qu'une seule application web pour une trentaine en Swing. J'ai donc skippé celles qui étaient exclusivement web où s'y focalisaient trop.

Enfin, merci :)