Le 27/02/2013 08:17, Adrien Cheype a écrit :
Quelques questions à la liste pour revenir à la problématique hors projet Cantharella.
Étant donné que l'inconvénient de ne pas définir les equals()/hashCode() implique à prendre en compte certains cas particuliers que je préférerais me passer, je me demande quelle serait la stratégie qui comportent le plus d'avantages. Pour mon information, Eric, pourrais-tu me donner plus de détails sur votre façon de générer un id depuis la couche DAO (et même un exemple de classe si possible) ?? Dans notre framework de persistence (ToPIA), les entités existent toujours avec une clé technique, le equals() et hashCode() sont donc basés sur des éléments techniques du framework qui existent dès la création de l'entité: http://maven-site.nuiton.org/topia/topia-persistence/xref/org/nuiton/topia/p... La clé est donc définie par le framework de persistence et non par la base de données.
Et le DAO qui permet de créer l'entité: http://maven-site.nuiton.org/topia/topia-persistence/xref/org/nuiton/topia/p... Dans le cas où c'est un id généré par la base de données, c'est tout de suite plus délicat.
La page suivante (https://community.jboss.org/wiki/EqualsAndHashCode) résume bien les différents problèmes qui peuvent survenir suivant les différentes stratégies (cf. "Summary"). La votre n'y est pas présentée, mais elle semble répondre aux quatre problèmes présentés. Le seul inconvénient que j'y vois semble qu'il n'est alors pas possible de garantir au niveau de la base une même logique d'affectation des identifiants (quid des autres moyens de renseigner la BD que via l'application en question ?).
J'avais pensé il y a déjà quelques temps à une autre stratégie ou l'on attribue un ID temporaire au niveau de l'application à la création puis que l'ID soit écrasé par la valeur attribué par la BD dès qu'il passe en persistance.
Une dernière solution très fréquente est de baser l'equals/hashcode sur les clés métiers. Bien qu'il faille prendre le temps de les définir pour chaque objet, il semblerait que ce soit la solution idéale lorsqu'on est sûr d'avoir une propriété immuable (ou une combinaison) pour le cycle de vie de l'entité. Dans le cas où l'entité n'ait pas de telles propriétés (c'est le cas notamment dans Cantharella), on entend deux sons de cloches : certains semblent dirent qu'il faille trouver une autre statégie, d'autres prétendent que contrairement à une clé primaire, ce n'est pas une obligation que les clés métiers ne changent pas, si cela se produit rarement (cf. extrait de "Java Pertinence with Hibernate" dans le sujet : http://stackoverflow.com/questions/2719877/object-equality-in-context-of-hib...).
Il faudrait être sur de ne pas utiliser l'entité en question dans une collection, le fait que le hashCode change pouvant causer des fuites mémoires.
Qu'en pensez-vous ? Des avis/préférences sur ces stratégies ?
Je ne vois pas d'autres stratégies qui permettent de définir correctement un equals/hashCode simple et propre. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com