在hibernate / jpa最佳实践问题中将独立实体或新实体与现有实体合并

一尘不染

在hibernate / jpa最佳实践问题中将独立实体或新实体与现有实体合并

hibernate

当业务层创建一个新的实体时，该实体在逻辑上表示应该更新的现有实体的实例（例如，它们共享相同的业务密钥），这是合并不良做法的方法吗？

public User add(User user){

    User existingUser = getUserDao().findByBusinessKey(user.getBusinessKey(), false);
    user.setId(existingUser.getId());

    user = getUserDao().merge(user);

    return user;
}

我问是因为在分离的实体上显式设置ID对我来说很奇怪，但是即使User实体的equals和hashcode方法得到了适当实现，在这里设置ID是确保合并发生的唯一方法。

有更好的做法吗？

此方法是否有特定的缺点，以后会困扰我？

谢谢参观！

阅读 260

2020-06-20

共1个答案

一尘不染

该代码将 起作用 ，但是不必在分离的实体上显式设置ID。典型的Hibernate应用程序具有处理两种情况的“保存”方法：

用户想要创建一个新用户，因此该应用程序创建一个ID为“ null”的User对象。
用户查询了一个用户列表，并且正在选择一个进行编辑。在这种情况下，应用程序会进行查询，并将对象传播到“保存”方法。该对象将具有一个ID，并且代码将对其应用新的值。

看起来您的代码中的某些内容没有以典型方式执行第二种情况。如果“用户”对象来自某个先前的Hibernate查询（通过用户单击“编辑用户”或类似内容触发），则该对象已经具有ID。因此，仅merge(user)需要呼叫。

我通常会这样：

if (user.getId() == null)
  em.persist(user);
else
  user = em.merge(user);

然后，我添加代码来处理乐观锁定问题（另一个会话更新了对象）和唯一约束问题（另一个会话尝试使用相同的业务密钥来持久化某些内容）。

诸如Seam之类的框架可以使这一过程变得更加简单，因为它们在控制器bean方法之间传播了Hibernate会话。因此，甚至不需要“合并”。

2020-06-20