Использование оболочки типа Integer или примитива int в отображении гибернации

Question

В компании, в которой я работаю, мы обсуждаем, следует ли лучше использовать классы обёртывания для примитивов (java.lang.Integer, java.lang.Long) или использовать типы примитивов непосредственно в POJO, которые отображают сущности в таблицы в Hibernate.

Идея состоит в том, что мы хотим, чтобы эти значения не были нулевыми в базе данных.

Аргументы в пользу использования примитивов:

• Обработка этих значений как int означает, что они никогда не могут быть нулевыми, в таким образом, делая невозможным непреднамеренное получение нулевой ссылки на поле.
• int = 32/64 бита памяти. Целое число = 16 байт памяти а также медленнее

Аргументы в пользу использования объектов-оболочек:

• Мы можем добавить ограничение на уровне базы данных, чтобы всегда предотвращать ноль значения от туда добраться
• Мы можем получить вводящие в заблуждение данные, мы можем иметь 0 вместо нуля в базе данных, когда пользователь не установить значение и ошибочные данные - сложная задача.
• Объекты обладают большей выразительной силой, чем примитивы. У нас есть нулевые значения, а также целочисленные значения, поэтому мы можем проверить их проще, используя аннотации для пример (javax.validation.constraints.NotNull).

Answer 1

Используйте обертки, сделайте свою жизнь проще.

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

Если они могут обнуляться в базе данных, используйте оболочки.Если они не обнуляются, и вы используете оболочки, то вы получите исключение, если попытаетесь вставить ноль в базу данных.

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

Я бы также поставил под сомнение ваше утверждение о том, что оно будет менее производительным.Вы измерили это?Я имею в виду действительно измерил это?Когда вы говорите с базой данных, есть гораздо больше соображений, чем разница между 16 битами и 32 битами.

Просто используйте простое, согласованное решение.Используйте обертки везде, если кто-то не даст вам очень вескую причину (с точной статистикой), чтобы поступить иначе.

Answer 2

думал, что стоит упомянуть:

Рекомендация Hibernate (раздел 4.1.2), использующая не примитивные свойства в постоянных классах, на самом деле ссылается - как указано - на свойства идентификатора :

4.1.2. Укажите идентификатор свойства

У Cat есть свойство id. Это свойство отображается в столбец (столбцы) первичного ключа таблицы базы данных. Свойство могло быть вызвано как угодно, и его тип мог быть любым примитивным типом, любым примитивным типом «оболочки», java.lang.String или java.util.Date.

...

Мы рекомендуем объявлять свойства идентификаторов с единообразными именами в постоянных классах и использовать обнуляемый (то есть не примитивный) тип.

Тем не менее, преимущества примитивов невелики:

1. Наличие несовместимого ненулевого значения в свойстве хуже, чем NullPointerException, так как скрывающуюся ошибку труднее отследить: пройдет больше времени с момента написания кода, пока не будет обнаружена проблема, и она может появиться совершенно другим код контекста, чем его источник.
2. Относительно производительности: перед тестированием кода - это, как правило, преждевременное рассмотрение. Безопасность должна быть на первом месте.

Answer 3

Документация Hibernate (только первая найденная мной версия) гласит:

Свойство могло называться как угодно, и его тип мог быть любым примитивным типом, любым примитивным типом «обертки», java.lang.String или java.util.Date.

...

Мы рекомендуем объявлять свойства идентификаторов с единообразными именами в постоянных классах и использовать обнуляемый (т.е. не примитивный) тип.

Таким образом, «голос эксперта» предлагает использовать Integer / Long ... но это не описано почему это так.

Интересно, может ли быть так, что объект, который еще не был сохранен, может быть создан без идентификатора (т. Е. Со значением свойства null), отличающего его от постоянных сущностей.