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