1. Pour récupérer tous les articles, la solution donnée ici ajoute une classe DaoArticle (seule les méthodes de recherche d'un article et de tous les articles sont données) qui contient une méthode qui fait une recherche "polymorphe" sur tous les articles. Attention, ce code n'est pas extensible puisqu'il sera indispensable de modifier le code si on ajoute un nouveau type d'article. On pourrait utiliser le modèle de conception "fabrique" ou la réflexivité pour rendre ce code extensible. Les outils ou frameworks de mapping OR permettent de résoudre simplement ce problème (voir suite du cours).
  2. Le plus simple, et sans doute le meilleur, est de laisser gérer les connexions par les classes qui utilisent les DAOs. Une connexion est passée en paramètre à chaque DAO (par une méthode setConnexion) après sa création. Ainsi, plusieurs méthodes, et même plusieurs DAOs, pourront partager une même connexion (et même une même transaction, les commit et rollback étant lancés par les classes clientes des DAOs). Une solution est développée dans l'exercice suivant du TP (Modèle "Fabrique abstraite" pour les DAO). Si la pattern "fabrique abstraite" est utilisé, la fabrique peut passer une connexion initiale à la création du DAO.
  3. Si vos méthodes "finder" renvoient un nouvel article à chaque fois, vous risquez d'avoir 2 objets qui correspondent à une même ligne de la base de données. Cette situation peut être dangereuse et conduire à des pertes de données. Pour éviter cela, la solution pourrait être, par exemple, d'utiliser un cache pour conserver tous les articles déjà utilisés pendant la session (une map, interface java.util.Map peut convenir dans les cas simples pour jouer le rôle de cache). Si un article est dans ce cache, le finder le renvoie sans accéder à la base de données. Ce cache peut être conservé dans une classe à part. On pourrait le mettre dans la classe Article mais ça n'est pas une bonne solution car il faut éviter de "polluer" les classes métier avec le code lié à la persistance. Avec JPA (vu plus loin dans le cours) le cache est géré par la classe EntityManager. Il faudrait aussi prévoir la possibilité de synchroniser les articles du cache avec la base de données pour le cas où un article aurait été modifié par une autre application dans la base de données.
  4. Que faire si les articles n'ont pas tous les accesseurs publics pour leurs variables d'instance ? Il est en effet possible qu'on ne veuille pas rendre explicitement accessibles certains attributs des articles par des accesseurs ou des modificateurs publics. Il existe des solutions complexes/astucieuses mais le plus simple est d'utiliser la reflexivité de Java qui permet aux classes qui en ont reçu l'autorisation de manipuler les variables d'instance private des objets. Il faudra donc donner cette autorisation aux DAOs ou autres classes qui en auront besoin. Toutes les classes chargées localement et sans gestionnaire de sécurité ont toutes les permissions (voir cours sur la sécurité en Java).

Pour simplifier les corrections, aucune factorisation de code n'a été faite. Si vous aviez à écrire tous les DAOs, vous vous apercevriez que de nombreuses séquences de code sont répétées dans les différents DAOs. Une meilleure architecture est évidemment possible avec, par exemple, une classe mère pour tous les DAOs (qui peut aussi implémenter une interface DAO) pour factoriser un maximum de code et fournir un modèle de méthode (template) pour les DAOs concrets. Cette classe mère sera sans doute générique, avec la classe de l'entité associée au DAO en paramètre de type (et aussi souvent la classe de l'attribut "clé primaire" comme autre paramètre de type).

Un des avantages de l'utilisation d'un outil ou d'un framework de persistance (tels les implémentations de la spécification JPA) est de libérer en partie le programmeur du genre de problèmes que l'on vient de voir dans cet exercice.