DAO / repository：插入/更新后的良好实践返回值

Question

虽然这可能是一个微不足道的问题，但我总是对这个问题感到疑惑。

通常，在插入db之后，通常的做法是返回业务实体的id。

@Override
public Long createUser(UserEntity user) {
    em.merge(user); 
    em.flush(); 

    return user.getId(); 
}

是否有令人信服的理由返回id而不是业务对象引用本身？

同样，我看到update返回void，而它也可能是id / User。

如果我要为其他人编写DAO /存储库，那么建议的返回值（如果有的话）是什么，为什么？

Answer 1

如果已成功创建/更新整个实例，为什么不返回？与Spring Data相同，

<S extends T> S save(S entity);
<S extends T> Iterable<S> save(Iterable<S> entities);

1. 如果我需要创建/更新对象的其他部分，id除外，我该怎么办？ （name实体的date，User。

2. 如果有一些字段可以准确表征实例（复合主键），为什么id会返回？

返回整个对象没有任何困难（@Danny Fonk所提到的没有任何“开销”），但它可能在将来节省很多时间。

Answer 2

根据我的经验，在插入过程中将id返回给业务实体是一种很好的做法，因为该id可能会使用full来继续业务流程，因为它是新输入的记录， 而且对于更新过程，我们在更新记录之前获取实体，这意味着我们已经获得了id，因此没有必要返回id

Answer 3

我还认为，如果不是最好的，那么返回ID通常是好的。或者您也可以返回整个对象，但如果您在创建后不再需要使用它，这有点“开销”。

在更新/更改数据库中的对象时，我们总是返回对象本身，或者很可能只是一个布尔值，因为我们已经有了对象，所以更新是成功的还是不成功的。

Answer 4

如果您返回实体，客户端代码将如下所示：

MyEntity e = ...;
MyEntity created = dao.create(e);

但“e”和“created”是同一个对象。这可能会导致混淆。您可以争辩说，您将来可以更改create方法的实现，以便它确实返回不同的实体。我见过这个。我不喜欢它。这是一个糟糕的持久性设计。

现在有一种情况我认为返回id是一个不错的选择：如果你的创建方法周围有一个事务边界（REQUIRES_NEW）。通过事务边界传递id而不是实体并不是坏事。