Discussion :

[cultureman]

Bonjour. Je viens tout juste découvrir le pattern DAO que je me pose quelque question. Par exemple sur OCR Herby propose

[joel.drigo]

Salut,

je me pose quelque question

Laquelle ?

[cultureman]

Oui , un oubli.
Pour la méthode find , il se peut qu'on veuille faire la recherche en fonction d'un autre critère que l'id. Dans ce cas faudrait-il utiliser 4 interfaces(pour chaque xxxDAO)?

[joel.drigo]

Le pattern DAO définit juste un moyen d'accèder à une source de données, de manière indépendant de cette source (que ça soit une base de données JDBC, un serveur de fichiers, un système de persistence d'objet, etc).

Il n'y a qu'une seule interface ici, qui définit le CRUD (Create/Read/Update/Delete) : les 4 actions qu'on peut avoir à faire. On pourrait découper en plusieurs interfaces, si on voulait séparer les notions "Lecture Seule" et "Lecture/Ecriture". La méthode find(id) donnée dans l'exemple, n'est qu'une version simplifiée de l'action Read. En plus rien n'empêche d'avoir plusieurs méthodes pour chaque action. Par exemple, on peut avoir une méthode find(id) pour trouver l'objet suivant son id, et une méthode find(IFilter) avec IFlter une interface fonctionnelle, pour trouver des enregistrements selon une combinaison de critères quelconques. tu peux même avoir une méthode getAll() (qui retourne un itérateur paginé, pas la liste de tous les enregistrement...).

[cultureman]

Merci beaucoup pour votre réponse. J'ai donc essayé de faire une méthode trouver un peu générique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
public OperateurPhysique[] trouver(String filtre, Object... objs) 
{
        ResultSet res;
        OperateurPhysique[] ops = null;
        String sql = "SELECT * FROM matable WHERE ";
        StringTokenizer tokens = new StringTokenizer(filtre, ";");
        int t = objs.length;
        for(int i = 0 ; i < t ; i++)
        {
            if(i == 0)
                sql += tokens.nextToken() + " =  " + objs[i];
            else
                sql += "AND " + tokens.nextToken() + " =  " + objs[i];
 
        }
 
       //reste du code
    }

Ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

trouver("nom;prenom" , "Lupin" , "Arsene")

exécutera la requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM matable WHERE nom = 'Lupin' AND prenom = 'Arsène'

Bien sur je compte utiliser des requêtes préparées plus tard.
Qu'en pensez vous?

[joel.drigo]

Bien sur je compte utiliser des requêtes préparées plus tard.
Qu'en pensez vous?

Je pense qu'il vaudrait mieux utiliser les PreparedStatement au plus tôt. Par contre, attention à la problématique d'être très lié à une base de données relationnelle SQL, dans le cadre général d'un DAO.
Dans la pratique, comme il est plus complexe de faire un DAO complètement générique du point de vue du système de persistance, on peut faire, comme tu as fait, un filtre SQL si on a un SGBD SQL, surtout qu'il y a peu de risque que cela change un jour dans l'application.

Mais, ça ne coûte pas grand chose et ce n'est pas spécialement très complexe de faire un filtre un peu plus abstrait, donc au lieu d'une chaîne de faire des interfaces pour manipuler un arbre de conditions, et faire une unique implémentation concrète qui transforme cet arbre en SQL. Ça prend beaucoup plus de temps quand même que pour une simple String, mais par rapport à un filtre pour PreparedStatement, on a des éléments similaires.
Ainsi, migrer d'une base vers autre chose, n'impliquera que l'implémentation du DAO concrète, pas les classes qui l'invoquent. De même pour le parcourt du résultat, qui devrait se faire en externe (pour rendre totalement transparent le parcourt de résultat réduit, complet, partiel, paginé, etc..., une sorte ResultSet DAO). C'est en tout cas un exercice intéressant à faire dans le cadre du travail sur les DAO.