JPA 最佳实践：静态查找实体答案

【问题标题】：JPA Best Practice: Static Lookup EntitiesJPA 最佳实践：静态查找实体
【发布时间】：2011-04-06 12:46:17
【问题描述】：

想象一下，一个 Event 实体引用了一个 Status 实体：

@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 映射到一个小表“status”。 Status是典型的参考数据/查找Entity。

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

我不确定将 Status 建模为实体是否是个好主意。感觉更像是常量的枚举……

通过将Status 映射为实体，我可以在Java 代码中使用Status 对象，并且Status 值同样存在于数据库中。这有利于报告。

另一方面，如果我想为一个事件设置一个特定的状态，我不能简单地分配我想到的恒定状态。我必须先查找正确的实体：

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

我可以避免上面的代码片段吗？我害怕性能损失，而且看起来很重......

我必须调整只读属性吗？
我可以预取这些查找实体并将它们用作常量吗？
我错过了一个重要的 JPA 功能吗？
...?

欢迎所有意见/建议/推荐！

谢谢！ J.

【问题讨论】：

标签： java hibernate orm jpa jakarta-ee

【解决方案1】：

我可以避免上面的代码片段吗？我害怕性能损失，它看起来很重？

好吧，您可以改用enum。我真的不明白你为什么不这样做。

但如果您真的想使用实体，那么它将是二级缓存的完美候选者，这将解决您的性能问题。

【讨论】：

我可以将 Status 建模为枚举。这将允许在事件中干净有效地设置状态值。 “代码”和“标签”都可以建模为属性。这也很酷。但是，我是否正确理解数据库中没有“标签”信息？这对于外部报告来说有点不幸：我的 Java 应用程序之外的工具可能想要访问数据库。还是我忽略了什么？枚举也可以映射到自己的数据库表吗？
我得仔细看看二级缓存。顺便说一下，您知道有哪些工具可以轻松监控 Hibernate 中的二级缓存吗？
@Jan 对，你不会在数据库中拥有带有枚举的标签。但我实际上会在枚举中使用Created、Initiated 等，而不是代码。无论如何，使用实体确实可能更好。在这种情况下，@Jörn 建议是一个很好的建议。尽管如此，这个只读实体仍然是 L2 缓存的完美候选者。关于监控，取决于二级缓存提供者。
谢谢。我同意我需要启动并运行这个 L2 缓存。

【解决方案2】：

您可以使用entityManager.getReference(Status.class, "CRD")，如果它仅用于设置外键，则可能无法从数据库中获取实体。

【讨论】：

好！这就是我一直在寻找的提示。