Dois-je écrire equals() et hashCode() méthodes dans des entités JPA?

Pas nécessairement. Il y a trois options:

• ne supplantent pas - donc, vous allez travailler avec les instances. C'est d'amende dans le cas où vous travaillez avec les collections avec seulement les entités qui sont attachés à la session (et donc la garantie d'être à la même instance). C'est (pour moi) la méthode privilégiée dans de nombreux cas, car il nécessite moins de code et de la considération lors de la substitution

• remplacer hashCode() et equals() avec une clé d'entreprise. Peut-être un sous-ensemble de propriétés qui permettent d'identifier l'entité. Par exemple, pour un User une bonne clé d'entreprise pourrait être le username ou la email. Ceci est considéré comme une bonne pratique.

• remplacer hashCode() et equals() à l'aide de l'ID de domaine seulement. C'est très bien, dans certains cas, surtout si vous avez une main-identifiant attribué (comme un UUID). C'est aussi bien si votre entité ne sera jamais aller dans une collection. Mais passagère entités (sans identifiant) qui entrent dans les collections, il provoque des problèmes, donc prudent avec cette option. Comme seanizer noté - vous devriez éviter. Généralement, toujours, à moins que vous êtes vraiment au courant de ce que vous faites (et peut-être en train de le documenter)

Voir cet article pour plus de détails. Notez également que equals()et hashCode() sont liés et doivent être mises en œuvre à la fois avec exactement les mêmes champs.

Oui, vous devriez!

Si vous n'en avez pas, remplacer la valeur par défaut Java.lang.Object equals et hashCode mise en œuvre:

@Entity(name = "Book")
public class Book implements Identifiable<Long> {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    //Getters and setters omitted for brevity
}

la merge opération sera de retour une autre instance de l'objet et de l'égalité contrat va être cassé comme expliquer dans ce post.

Le meilleur moyen est d'utiliser une clé d'entreprise, comme ceci:

@Entity
public class Book implements Identifiable<Long> {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @NaturalId
    private String isbn;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Book)) return false;
        Book book = (Book) o;
        return Objects.equals(getIsbn(), book.getIsbn());
    }

    @Override
    public int hashCode() {
        return Objects.hash(getIsbn());
    }

    //Getters and setters omitted for brevity
}

Vous pouvez également utiliser l'identificateur de l'égalité, mais l'esprit que le hashCode de la mise en œuvre devrait toujours retourner la même valeur, comme expliqué dans le même poste que je l'ai déjà mentionné:

@Entity
public class Book implements Identifiable<Long> {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Book)) return false;
        Book book = (Book) o;
        return Objects.equals(getId(), book.getId());
    }

    @Override
    public int hashCode() {
        return 31;
    }

    //Getters and setters omitted for brevity
}

Nous avons tendance à laisser IDE générer hashCode() et equals() pour nous. Attention tout de même. Lorsque vous générez ces méthodes pour des Entités JPA. Certaines versions de equals() vérifie identité de classe

//... inside equals() - wrong approach for Entities (cause of generate proxies)
if (o == null || this.getClass() != o.getClass()) {
        return false;
}
//...

Ce serait briser vos collections avec certains JPA bibliothèques les bibliothèques de créer des procurations pour vos entités (sous-classes), comme par exemple MyGreatEntity_$$_javassist_7 en veille prolongée.

Dans des Entités toujours autoriser les sous-classes dans equals().