0

Clarification question on saving entities best practice.

What is the purpose of returning an entity that you might have just saved in a repository? I see the benefit of returning it's Id once it's been created but not the whole entity. Can someone please explain the purpose or benefit in returning the entity.

Improve this question
10
  • Generally speaking, if you are calling a createOrUpdate method, and update a specific field of an entity, returning the whole object instead of only an id makes sense, since you might want to do something after the update, which saves you a retrieveById kind of call
    – Bruno Oliveira
    Jan 8, 2020 at 15:22
  • But if you updated an entity surely you already have that entity and know what was updated so don't need it back from the call?
    – David Hawkins
    Jan 8, 2020 at 15:41
  • Please cite the source of the recommendation or best practice.
    – Martin K
    Jan 8, 2020 at 15:49
  • @BrunoOliveira: Whoever called the createOrUpdate method already knew what the object contained (since they supplied it to the createOrUpdate method), why would they need to re-fetch the same information again? Furthermore, doublestacking an update and fetch in the same method violates SRP.
    – Flater
    Jan 8, 2020 at 15:50
  • 2
    David, are you sure that there are no triggers or other manipulations that go with that? Example field updates would include Id, CreatedAt, CreatedBy, ModifiedAt, ModifiedBy. ORM tools sometimes manage standard audit tracking fields like that, so returning the whole object guarantees that the object matches the database.
    – Berin Loritsch
    Jan 8, 2020 at 21:26

1 Answer 1

Reset to default
1

I'd like to start by saying that there are no established "best practices" for writing create and update methods. There are common needs, and sometimes the library you are using will take care of certain metadata for you. Some more common examples would include:

  • Updating audit fields (created/modified timestamp and user)
  • Assigning the identifier
  • Updating the object after any database triggers mutate data during your write (like creating a Geo Spatial point from a pair of coordinate fields)

That said, there are tools that simply return the success or failure of the action. It really depends on the interactions you want to guarantee. You may not care about the object after you write it (not uncommon in web APIs). You may need to refresh your UI afterwords in a desktop environment, so having the updated object is helpful in that case.

It's becoming more popular to "upsert" (update a record, or insert it if it doesn't exist) because that is what is useful on a good number of projects. However, it isn't something that is expected in your ORM tool.

Trade-offs

  • In the stateless web, the returned object can be wasteful
  • In a desktop, it can save time

There is no one-size fits all solution, and the best practice is the one that best fits the application you are building.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.