JPA: не переопределяет equals () и hashCode () в сущностях? - PullRequest
3 голосов
/ 04 марта 2011

После прочтения этой статьи , я склоняюсь к тому, чтобы не переопределять equals () и hashCode () в целом.

В кратком изложении этой статьи, касающейся колонки no eq / hC вообщеединственное последствие - то, что я не мог выполнить операции сравнения, такие как:

  1. contains () в Списке для отсоединенных сущностей, или
  2. сравнение одних и тех же сущностей из разных сессий

и ожидайте правильного результата.

Но я все еще сомневаюсь и хотел бы спросить ваш опыт об этом, является ли это плохой практикой вообще пропускать равные и hashCode и какие другие последствия ядо сих пор не знаю.

Просто еще один пункт информации, который я собираюсь использовать, используя List Collections over Set.И я предполагаю, что мне не нужно переопределять hashCode и равны при хранении в List.

Ответы [ 3 ]

3 голосов
/ 04 марта 2011

Вы получили прямо противоположный вывод из этой статьи о том, что он пытался донести.

Hibernate в значительной степени полагается на равные, реализованные правильно. Если вы этого не сделаете, произойдет сбой.

На самом деле, почти все делают; включая стандартные коллекции Java.

Реализация по умолчанию не работает при использовании постоянства. Вы должны всегда использовать как равные, так и хэш-код. Существует также простое правило, как это сделать:

  • Для сущностей используйте ключ объекта.
  • Для объектов-значений используйте значения

Всегда проверяйте, что значения, которые вы используете в вашем equals / hashcode, являются неизменяемыми. Если вы раздаете их (как в получателе), желательно раздавать их в неизменяемой форме.

Этот совет улучшит вашу жизнь :)

3 голосов
/ 04 марта 2011

Прочитайте эту очень хорошую статью на эту тему: Не позволяйте Hibernate украсть вашу личность .

Вывод статьи выглядит так:

Идентификация объекта обманчиво трудно реализовать правильно, когда объекты сохраняются в базе данных.Однако проблемы полностью связаны с тем, что объекты могут существовать без идентификатора до их сохранения.Мы можем решить эти проблемы, взяв на себя ответственность за присвоение идентификаторов объектов за пределами структур объектно-реляционного отображения, таких как Hibernate.Вместо этого идентификаторы объекта могут быть назначены, как только объект будет создан.Это делает идентификацию объекта простой и безошибочной, а также уменьшает объем кода, необходимого в модели предметной области.

3 голосов
/ 04 марта 2011

является ли это плохой практикой пропускать все равно и хэш-код

Да.Вы должны всегда переопределять ваши equals и hashCode.Период.Причина в том, что этот метод уже присутствует в вашем классе, реализованном в Object.Оказывается, что эта реализация является общей, и почти в 100% случаев это неправильная реализация для ваших собственных объектов.Таким образом, пропуская equals / hashCode, вы фактически предоставляете неверную реализацию и в лучшем случае будете сбивать с толку тех, кто использует эти классы.Это могут быть ваши коллеги или используемая вами среда (которая может привести к непредсказуемым и трудным для отладки проблемам).

Нет никаких оснований для , а не для реализации этих методов.,Большинство IDE предоставляет генератор для equals / hashCode.Вам просто нужно сообщить IDE о вашем бизнес-ключе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...