Description
This issue is related to #502 in the sense that it's also about cleaning up the default repository layer
Issue:
in CreateAsync
the values that are stored in the database are a direct result of the values of the properties of the to-be-created. This makes sense, because in the service layer, the following call is made: await _repository.CreateAsync(entity)
, and intuitively, any changes that are made on entity
in eg a custom service will be included by the repository create action.
The UpdateAsync
method is called in a very similar way: as await _repository.UpdateAsync(id, entity)
and therefore one would expect roughly the same idea. However, the entity
parameter that is being passed is not used at all, and therefore, any manual changes (in a custom service) that are done on this object do not affect the database at all.
This is a problem:
- This is confusing because it suggests differently, as explained with the CreateAsync approach.
- It is also internally inconsistent: in the
UpdateAsync
method, all to-be-updated values and relationships are retrieved fromIJsonApiContext
and pushed to the database, without using thisentity
parameter, whereas inCreateAsync
the values on the actualyentity
parameter dictate what is pushed to the database. - Any changes done on the
entity
parameter through resource hooks in the case ofUpdateAsync
are lost. This beats the purpose of being able to use business logic.
I think UpdateAsync
should be changed to also work on the actual entity
parameter. It is still better to first get the current state of the entity (oldEntity
), make changes on this and then SaveChanges
, because this will result in more efficient queries, but the values to put on oldEntity
should be retrieved from the entity
parameter, not IJsonApiContext
.