无状态REST应用中Spring Data JPA实体状态更新常用实现模式咨询

行业通用的标准实现是第一种方案：DTO携带ID时先加载已有持久态实体，再覆盖DTO属性后调用save()，无ID时新建实体实例。

核心原因如下： #

• 保证乐观锁逻辑正常生效
  第二种方案直接新建带ID的实体执行save()时，Spring Data JPA会触发merge操作，如果新建实体未携带@Version注解标注的乐观锁字段值，Hibernate会直接跳过版本校验强制覆盖数据库记录，乐观锁完全失效，无法避免并发更新导致的脏写问题。第一种方案从数据库加载的持久态实体自带当前最新版本号，属性更新后自动触发版本校验，完全符合乐观锁的设计预期。
• 保障Hibernate Envers审计日志准确性
  Envers的审计能力依赖EntityManager对实体字段变更的跟踪能力：第二种方案中新建的游离态实体执行merge时，Hibernate需要全量对比新实体和数据库存量记录的所有字段生成变更日志，很容易出现不必要的版本记录，甚至会因为DTO未传递的字段被赋值为默认值，误生成字段变更的审计记录。第一种方案下仅会跟踪DTO实际覆盖的字段变更，生成的审计日志和业务操作完全对齐。
• 避免非预期的数据覆盖
  绝大多数业务场景下，接口返回的DTO仅包含允许修改的部分字段，而非实体全量字段。第二种方案新建实体拷贝DTO属性后，未被赋值的字段会保留Java默认值（null、0、空字符串等），执行save()后会直接覆盖数据库中原本的非空值，引发数据丢失。第一种方案加载的存量实体会保留所有原有字段值，仅覆盖DTO映射的属性，不会出现意外的数据覆盖。
• 简化关联关系维护
  如果实体包含一对一、一对多等关联属性，第一种方案加载的持久态实体已经持有正确的关联关系，仅需调整业务需要修改的关联即可。第二种方案如果未手动全量设置所有关联属性，执行save()后会直接清空原有关联关系，引发的业务问题排查成本极高。

第二种方案的适用场景 #

仅当接口每次都会传递实体的全量字段（包括乐观锁版本号、所有关联属性、所有业务字段），且业务逻辑本身要求全量覆盖实体所有字段时，第二种方案才可以使用，该场景在实际业务开发中占比极低。 #

内容的提问来源于stack exchange，提问作者Jochen Schmitz