当业务层创建一个新的实体时,该实体在逻辑上表示应该更新的现有实体的实例(例如,它们共享相同的业务密钥),这是合并不良做法的方法吗?
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是确保合并发生的唯一方法。
有更好的做法吗?
此方法是否有特定的缺点,以后会困扰我?
谢谢参观!
该代码将 起作用 ,但是不必在分离的实体上显式设置ID。典型的Hibernate应用程序具有处理两种情况的“保存”方法:
看起来您的代码中的某些内容没有以典型方式执行第二种情况。如果“用户”对象来自某个先前的Hibernate查询(通过用户单击“编辑用户”或类似内容触发),则该对象已经具有ID。因此,仅merge(user)需要呼叫。
merge(user)
我通常会这样:
if (user.getId() == null) em.persist(user); else user = em.merge(user);
然后,我添加代码来处理乐观锁定问题(另一个会话更新了对象)和唯一约束问题(另一个会话尝试使用相同的业务密钥来持久化某些内容)。
诸如Seam之类的框架可以使这一过程变得更加简单,因为它们在控制器bean方法之间传播了Hibernate会话。因此,甚至不需要“合并”。