JPA Best Practice: Статические объекты поиска - PullRequest
12 голосов
/ 01 сентября 2010

Представьте себе, Событие объект ссылается на Статус Объект:

@Entity
@Table(name = "event")
public class Event()
{
  @Id
  @Column(name = "id", nullable = false)
  private long id;
  ...

  @ManyToOne
  @JoinColumn(name = "status_code", nullable = false)
  private Status status;
}


@Entity
@Table(name = "status")
public class Status()
{
  @Id
  @Column(name = "code", nullable = false)
  private String code;

  @Column(name = "label", nullable = false, updatable = false)
  private String label;
}

Статус сопоставлен с небольшой таблицей 'status». Статус - это типичная справочная / поисковая сущность.

   code  label
   ----- --------------
   CRD   Created
   ITD   Initiated
   PSD   Paused
   CCD   Cancelled
   ABD   Aborted

Я не уверен, что это хорошая идея - моделировать Статус как сущность.Это больше похоже на перечисление констант ...

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

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

event.setStatus(entityManager.find(Status.class, "CRD"))

Можно ли избежать фрагмент кода выше?Я боюсь за снижение производительности, и это выглядит очень тяжело ...

  • Нужно ли настраивать объекты только для чтения?
  • Можно ли предварительно выбрать эти объекты поиска и использовать их в качестве констант?
  • Я пропустил важную функцию JPA?
  • ...?

Все мнения / предложения / рекомендации приветствуются!

Спасибо!J.

Ответы [ 2 ]

9 голосов
/ 01 сентября 2010

Вы можете использовать entityManager.getReference(Status.class, "CRD"), который может не извлечь объект из базы данных, если он используется только для установки внешнего ключа.

3 голосов
/ 01 сентября 2010

Могу ли я избежать фрагмент кода выше? Я боюсь штрафа за производительность, и это выглядит очень тяжело?

Ну, вместо этого вы можете использовать enum. Я действительно не понимаю, почему вы на самом деле нет.

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

...