Персит случайный UUID, служащий в качестве объекта ID объекта JPA?

Question

Мне нравится использовать класс BaseDomain для всех моих объектов домена JPA. В базовом классе у меня есть идентификатор объекта, который хранится как строка, сгенерированный из UUID.random(). Идентификатор объекта присваивается при создании объекта. Класс сущности также имеет первичный ключ, назначенный базой данных при сохранении.

До этого момента я всегда сохранял идентификатор объекта на основе String. Это добавляет дополнительный столбец для каждой таблицы, но это меня не беспокоит.

Мне было интересно - Есть ли причина для сохранения идентификатора объекта (сгенерированного UUID)? Или должен ли случайный UUID оставаться в пространстве Java?

Я всегда основываю свои методы hashCode() и equals() класса домена на UUID, а не на первичном ключе. Это нормально, потому что UUID остается неизменным для данного объекта на протяжении всей его жизни, как в JVM, так и в базе данных.

Если я перестаю упорствовать в UUID, как выглядят методы hashCode() и equals()? Было бы это похоже на сравнение двух уровней, сначала используя первичный ключ, если он не является нулевым, а затем использует идентификатор объекта, если первичный ключ равен нулю?

Answer 1

Правильная реализация equals и hashCode является предметом особой проблемы для сущностей.

Вам не нужно настаивать на дополнительном ключевом значении бизнеса, если у вас есть «естественный» первичный ключ, например, номер социального страхования для человека. Это может быть одно значение или комбинация значений - как комбинация имени, фамилии, даты рождения и адреса. Если у вас есть такой натуральный ПК, используйте его. Если у вас его нет, использование UUID - прекрасный способ его создать.

Если вы используете UUID для equals и hashCode, вы также должны его сохранить, поэтому два экземпляра одной и той же записи считаются равными.

Ваши equals10 и hashCode должны быть основаны на этом деловом ключе, а не на идентификаторе, предоставленном DB. При использовании id, предоставленного DB, все новые объекты считаются равными. Это может привести к неожиданному поведению, особенно при работе с коллекциями.