JPA. Лучшие практики: объекты статического поиска

Представьте, что объект Event ссылается на Status Entity:

@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.

12
задан Pascal Thivent 31 August 2010 в 22:37
поделиться

1 ответ

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

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

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

3
ответ дан 2 December 2019 в 21:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: