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

Although probably a trivial question, I've always wondered about this.

虽然可能是一个微不足道的问题，但我一直都在想这个问题。

Usually, after insertion into the db, it seems common practice to return the id of the business entity.

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

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

    return user.getId(); 
}

Is there a convincing reason for returning the id instead of the business object reference itself?

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

Similarly, I've seen update return void, while it might just as well be an id / User.

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

If I were to write a DAO / Repository for others to use, what would be the advised return value (if any), and why?

如果我要为其他人编写一个DAO / Repository来使用，那么建议的返回值是什么（如果有的话），为什么？

4 个解决方案

#1

Why not return the whole instance if it has been created/updated successfully? The same what Spring Data do,

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

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

What have I to do if I need another part of the created/updated object, except id? (name, date for a User entity).

如果我需要创建/更新对象的另一部分，除了id，我该怎么办？（用户实体的名称，日期）。
Why does id return if there are a few fields that exactly characterise an instance (a composite primary key)?

如果有几个字段准确表征实例（复合主键），为什么id会返回？

There is no difficulty to return the whole object (nothing is "overhead" here as mentioned by @Danny Fonk), but it may save much your time in the future.

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

#2

As per my experience , In insertion process return the id to the business entity is good practice because that id might be use full to continue the business process as it is newly entered record , moreover for the update process we fetch the entity before we update the record so that means we already got the id , so it's not necessary to return the id

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

#3

I also think that returning the ID in general is good if not even best practive. Or you can also return the whole object but this is kinda "overhead" if you don't need to work with it anymore after creation.

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

At updating/altering an object in the database we always return the object itself or most likely just a boolean wether the update was succesfull or not since we already have the object.

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

#4

If you return the entity, the Client code would look like this:

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

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

but "e" and "created" are the same object. This can lead to confusion. You could argue that you can in future change the implementation of your create Method so that it really does return a different entity. I've seen this. I didn't like it. It was imho a terrible persistence design.

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

Now there is one Situation where I think returning the id is a good option: If you have a transaction boundary (REQUIRES_NEW) around your create Method. Passing ids instead of entities through transaction boundaries is not a bad thing.

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

#1