I have been trying to reason about the best way to handle whether it is generally good practice to implement hashcode and equals on entities (I mean entity in the general sense but in most cases it will be a JPA entity).
In Chapter 24 of the Hibernate manual http://docs.jboss.org/hibernate/core/3.3/reference/en/html/best-practices.html it says this...
Identify natural keys for all entities, and map them using . Implement equals() and hashCode() to compare the properties that make up the natural key.
It makes sense to have .equals and .hashcode include only these natural keys but what if you have more than one instance of the same entity (same natural id thus same hashcode)? It seems like this practice could have subtle implications elsewhere in your application. Has anybody tried this before on a large scale?
There are times when you want Equals to compare all properties and times when you want Equals to be just the key. We've had a lot more success using helper classes that are explicit so there isn't ambiguity as to what's being compared.
ByKeyComparer.Equals...
ByPropertiesComparer.Equals...
or
Entity1.EqualsByKey...
Entity1.EqualsByProperties...
I've tried this before on a large scale (or at least in an application that heavily uses hibernate). It's a good idea.
It makes sense to have .equals and .hashcode include only these natural keys but what if you have more than one instance of the same entity (same natural id thus same hashcode)? It seems like this practice could have subtle implications elsewhere in your application.
This is what it's meant for. You typically want multiple instances of the same entity to succeed when comparing .equals, and yes, it has implications elsewhere. IMO those implications are that things would work as expected.
来源：https://stackoverflow.com/questions/1929445/to-equals-and-hashcode-or-not-on-entity-classes-that-is-the-question