Создание идеального JPA сущности

При работе с JPA (Java Persistence API) разработчики часто сталкиваются с трудностями при создании сущностей. Это может быть связано с выбором типа доступа, неизменяемостью свойств, реализацией методов equals/hashCode и другими вопросами.

Класс сущности

Классы сущностей обычно реализуют интерфейс Serializable. Это требование спецификации, хотя некоторые провайдеры JPA, например, Hibernate, не требуют этого. Тем не менее, если Serializable не реализован, Hibernate может завершиться с ошибкой ClassCastException.

Конструкторы

В классе сущности обычно создают конструктор с обязательными полями. Это позволяет гарантировать, что экземпляр класса всегда будет находиться в корректном состоянии.

Кроме того, в классе сущности должен быть конструктор по умолчанию с уровнем доступа package private. Hibernate использует его для инициализации сущности. Приватный конструктор допустим, но для генерации прокси-объектов во время выполнения и эффективной загрузки данных без инструментации байт-кода требуется уровень доступа package private или public.

Поля/Свойства

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

Сеттеры для неизменяемых полей не требуются для типа доступа к полю. Свойства могут быть приватными. Несмотря на то, что некоторые источники утверждают, что protected уровень доступа лучше для производительности Hibernate, в документации указано, что Hibernate может обращаться к public, private и protected методам доступа, а также к public, private и protected полям напрямую.

Equals/hashCode

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

Важно не ссылаться на связанные сущности (ManyToOne) в equals/hashCode. Если такая сущность должна быть частью бизнес-ключа, стоит сравнивать только их ID. Вызов getId() на прокси не вызовет загрузку сущности, если использовать тип доступа к свойству.

В заключение, создание идеальной JPA сущности — это процесс, который требует понимания особенностей работы JPA и Hibernate. Надеемся, что эти рекомендации помогут вам в этом.