Discussion :

[superJiBi]

Bonjour,

Je développe en Java, et je dois réaliser un projet Web.
Ce n’est peut-être pas le bon forum, mais ma question concerne essentiellement l’accès aux données et au DAO.

J’ai bien mis en place les objets modèles, le DAO et les services.

Quand j’interroge la base via mon DAO qui doit me renvoyer un seul élément (interrogation par l’ID), que doit me renvoyer le DAO ?

Par défaut, je renvoie un objet « vide », dans lequel j’ai ajouté un attribut qui m’indique si j’ai trouvé ou non cette objet.

Exemple :

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
21
22
23
24
25
26
27
28
 
       // début de la méthode
       Utilisateur utilisateur = null;
 
       try {
           cx = getConnexion();
           st = cx.prepareStatement("select user, username, password from utilisateur where id = ?");
           st.setString(1, id);
           rs = st.executeQuery();
           if (rs.next()) {
               String nom = rs.getString(1);
               String prenom = rs.getString(2);
               String motDePasse = rs.getString(3);
 
               utilisateur = new Utilisateur();
               utilisateur.setIdentifiant(id);
               utilisateur.setNom(nom);
               utilisateur.setPrenom(prenom);
               utilisateur.setMotDePasse(motDePasse);
		utilisateur.setTrouve(true) ;
 
           }
} catch (Exception e) {
       utilisateur = new Utilisateur();
	utilisateur.setTrouve(false) ;
}
 
return utilisateur ;

Ce fonctionnement me semble avantageux, car dans tous les cas je récupère un Utilisateur.
Ensuite, il y a juste à vérifier si on l’a bien trouvé avec une méthode isTrouve().

Quand pensez-vous ?

Mes collègues ne sont pas d’accord avec moi, pouvez-vous me donner quelques arguments pour les convaincre ?

[thebloodyman]

Par défaut, je renvoie un objet « vide », dans lequel j’ai ajouté un attribut qui m’indique si j’ai trouvé ou non cette objet.

Ce fonctionnement me semble avantageux, car dans tous les cas je récupère un Utilisateur.
Ensuite, il y a juste à vérifier si on l’a bien trouvé avec une méthode isTrouve().

Désolé mais je peux pas vraiment t'aider

Un Dao pait partie de la couche d'accès aux données. Il n'est pas censé te créer d'objet si il y en a pas en base.
Ensuite le fait de toujours renvoyé un objet oblige le client du service dao de vérifier lors du retour de l'appel, le résultat returnedObject.isTrouve().
C'est pas forcément intuitif comme procédé.
Si la requête ne trouve pas de résultat, on s'attend généralement à recevoir null de ton DAO.
Pourquoi ? C'est plutôt logique, courant dans les api java et enfin tu gagnes en concision de code tant coté client dao (vérif à null suffit) que dao (tu renvoies directement null).
Ex api java: quand tu fais un get(Objet key) sur une Map, si aucune clef n'est enregistré dans la map, tu reçois null.

[fr1man]

Ou tu peux aussi utiliser une exception.

[thebloodyman]

Ou tu peux aussi utiliser une exception.

Quel intérêt ?
Si elle est de type runtime et qu'elle est pas catché coté client, ca va faire planter l'application alors que c'est pas le comportement demandé (vu le if isTrouve).
Si elle est de type checked, c'est pas beaucoup mieux, ca oblige à écrire du code pour la catcher coté client.

Une exception lancée par un client est faite principalement pour :
- arrêter l'application lors d'une erreur irrécupérable.
- remonter une erreur métier et ou technique et laisser une chance à l'appelant de traiter l'erreur.
- ajouter de la sémantique à l'erreur lorsqu'il y en a plusieurs de possibles pour un même service(ce qu'un boolean ne permet pas par exemple)

Le cas présenté n'entre dans aucun des cas ou l'exception apporte un avantage.
Si on lance des exceptions à chaque fois que nos services ne renvoient pas de résultat, bonjour le code illisible.

[fr1man]

Donc les auteurs des frameworks, de type Hibernate, qui génèrent ce type d'exception n'ont rien compris ?

[thebloodyman]

Je savais pas qu'Hibernate te renvoyait une exception lorsqu'il n'y avait pas de résultat à une réquête de type find(id).
Faudrait que tu me donnes ta version d'Hibernate

[Baptiste Wicht]

Personnellement, je suis plus pour renvoyer null qu'un objet spécial comme tu le fais.

De toute façon que ce soit null ou un booléen, il faudra bien faire le test coté client...

En plus de cela, tu crée un objet qui n'est pas un utilisateur et c'est pas logique un booléen trouvé dans un objet Utilisateur. Si tu veux vraiment retourner un objet, retourne un objet Resultats qui contiendra le ou les utilisateurs trouvés et dans le cas ou il y a rien un appel à isEmpty retournera true. C'est à mon avis plus propre du côté sémantique, mais c'est un peu extrême.

[fr1man]

Je précise pour "monsieur je sais tout", qu'avec Hibernate, on peut récupérer une entité de deux façons (entre autres) possibles.
- soit par la méthode get qui renvoie null si l'entité n'est pas trouvée
- soit par la méthode load, qui renvoie une exception si l'entité n'est pas trouvée

A voir selon les cas d'utilisation.

[thebloodyman]

Je précise pour "monsieur je sais tout", qu'avec Hibernate, on peut récupérer une entité de deux façons (entre autres) possibles.
- soit par la méthode get qui renvoie null si l'entité n'est pas trouvée
- soit par la méthode load, qui renvoie une exception si l'entité n'est pas trouvée

A voir selon les cas d'utilisation.

Oui et si tu avais bien lu les raisons pour lesquelles j'explique qu'il est utile de lancer une exception, tu comprendrais que findUnique() d'Hibernate rentre dans ce cas la :
- remonter une erreur métier et ou technique et laisser une chance à l'appelant de traiter l'erreur.
-> Tu t'attends à avoir qu'un seul objet donc tu fais péter l'exception.

Or, je vais pas me répéter 500 fois mais dans l'exemple de l'auteur, aucune raison valable (ex: erreur métier) n'encourage à lever d'exception.
Si t'as une seule raison valable pour lancer une exception dans ce cas, explique nous.
Car a part pour avoir du code superflu, je vois pas.

[fr1man]

Inutile de prendre ce ton hautain, ça ne te donnera pas plus de crédibilité.

Je ne dis pas qu'il faut impérativement lancer une exception, je dis que ça peut être une éventualité selon les cas. Tout dépend de ce que veut l'auteur, au moins, il saura que cela existe.
Si l'on est certain que la donnée est en base, on peut donc considérer comme une erreur le fait qu'elle n'y soit pas et ainsi lancer une exception. C'est le principe du load.

[thebloodyman]

Inutile de prendre ce ton hautain, ça ne te donnera pas plus de crédibilité.

La bonne blague
C'est moi qui ait dit ca ?

Je précise pour "monsieur je sais tout",

Passons...

Si l'on est certain que la donnée est en base, on peut donc considérer comme une erreur le fait qu'elle n'y soit pas et ainsi lancer une exception. C'est le principe du load.

Je suis d'accord sur le principe.
Mais je te rappelle une chose : tu as proposé de lancer une exception dans le contexte de l'auteur.
Or dans le contexte de l'auteur, il n'a jamais été question que l'user à chercher était forcément en base.
Je pense que le but du forum est d'apporter des solutions qui répondent aux besoin des gens qui postent. Si il y a des alternatives, c'est intéressant de les montrer, bien-sûr. Maintenant si il y aucune argumentation et explication dans le cas ou l'alternative est utile. Pire même, si l'alternative n'est pas la bonne solution dans le contexte présenté par l'auteur du sujet, ca revient à faire de la désinformation.

[fr1man]

Ma proposition n'est pas hors sujet.
Elle correspond à ce que demander l'auteur, une récupération d'entité par un id.
On est loin de la désinformation que tu prétends.
J'arrêterai donc là ce dialogue de sourds.

[superJiBi]

Pour conclure, je vois que personne n'est d'accord avec moi.

Mais, c'est bien ma méthode qui a été mise en place.

Merci à tous.