Hibernate/JPA - аннотирование методов bean и полей

У меня есть простой вопрос об использовании Hibernate. Я продолжаю видеть людей, использующих аннотации JPA одним из двух способов, аннотируя поля класса, а также аннотируя метод get на соответствующем beans.

Мой вопрос таков: существует ли разница между аннотирующими полями и методами bean с аннотациями JPA, такими как @Id.

Пример:

@Entity
public class User
{

**@ID**
private int id;

public int getId(){
return this.id;
}

public void setId(int id){
this.id=id;
}

}

----------- ----------- ИЛИ

@Entity
public class User
{


private int id;

**@ID**
public int getId(){
return this.id;
}

public void setId(int id){
this.id=id;
}

}

Ответы

Ответ 2

Да, если вы аннотируете поля, Hibernate будет использовать доступ к полю для установки и получения этих полей. Если вы аннотируете методы, спящий режим будет использовать геттеры и сеттеры. Hibernate выберет метод доступа, основанный на местоположении аннотации @Id, и, насколько мне известно, вы не можете смешивать и сопоставлять. Если вы аннотируете поле с помощью @Id, аннотации к методам будут проигнорированы и наоборот. Вы также можете вручную установить метод с аннотацией уровня класса @AccessType

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

Ответ 3

Зачем вам аннотировать аксессуры? Это просто выглядит беспорядочно, и это боль для поддержания. Теперь я должен охотиться во всем классе, чтобы узнать, как применяется JPA или Hibernate. При работе с некоторыми плагинами генерации кода Hibernate для Eclipse это значение по умолчанию, и оно меня шокирует.

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

Ответ 4

Моя рекомендация - аннотировать методы. Поступая таким образом, вы получаете небольшую гибкость. Например, допустим, у вас есть несколько классов:

  • AbstractEntity
  • StringIdEntity
  • AutoIdEntity

AbstractEntity определяет поле id/getter/setter. Классы StringIdEntity и AutoIdEntity наследуют от AbstractEntity, но используют разные стратегии @Id. Если вы аннотируете поле, вы не можете изменить его из класса в другой.

Если вы комментируете методы, вы помечаете getId() как @Transient/abstract в AbstractEntity, а затем в подклассах вы просто переопределяете метод и применяете стратегию, которую хотите использовать. Раньше я сам писал аннотации и сталкивался с этим, и решил, что всегда буду комментировать методы продвижения вперед.

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

Ответ 5

Является ли ответ apeped для спящего режима для других версий JPA?

Ответ 6

Существует несколько вариантов обсуждения, которые дают преимущество использованию свойства FIELD над свойством (см. http://java.dzone.com/tips/12-feb-jpa-20-why-accesstype). Даже среда spring также рекомендует использовать свойство FIELD над свойством (см. http://static.springsource.org/spring/docs/2.5.x/reference/orm.html). Я нахожу FIELD более чистым подходом не только потому, что вы не вынуждены внедрять сеттеры/геттеры, но вы можете иметь свои настраиваемые сеттеры/геттеры в своем классе. Так что лучше инкапсуляция и более чистые классы. Эффективное поле FIELD имеет немного преимущество над PROPERTY, но это незначительно.

В одной строке используйте FIELD over PROPERTY. Используйте PROPERTY, если вам это действительно нужно.