Effective approach to update in disconnected EF Core
c# database entity-framework entity-framework-core postgresql
Question
I have an ASP Dotnet Core web service. This talks to a Postgres database using Entity Framework Core 1.1. When the service needs to update a database record in response to a client request there are two approaches.
Approach 1
Retrieve the record to be updated from the database.
Map the values recieved from the client onto the database entity.
Call SaveChanges on the database context.
Approach 2.
Call Update on the database context passing in the record recieved from the client. (Mapping from a DTO to database entity if required).
Call SaveChanges on the database context.
The two approaches behave very differently.
Approach 1
Pro. Updates just those values that have been changed from the values in the database.
Con. Takes two database round trips to perform. (Retrieve entity then update).
Approach 2.
Pro. Takes only one database round trip to perform.
Con. Updates the entire object graph passed in, even if only one value in the entities has changed.
The page in the Entity Framework Core documentation on working with disconnected entities has yet to be written.
https://docs.microsoft.com/en-us/ef/core/saving/disconnected-entities
We don't have a full production system in place with sufficient data to test this effectively, and at this stage of development where we are trying to resolve the parts of our application with the most risk, empirical evidence based optimisation is not sufficiently high priority for us to invest this time right now.
Given that the webserver and the database server will live within the same datacenter, what I'm looking for is a somewhat informed 'starter for 10' approach that we might take the time to optimise later, should the need arise.
The problem I have though is that these two approaches behave so totally differently but I have found no information that helps me choose between them, and without a realistically sized test system with representative throughput I suspect that the interpretation of any quick and simple local tests I could do would be largely meaningless wrt to the bandwidth and occupancy of a production scale system.
I would welcome pretty much any information or guidance.
Popular Answer
You might find the ASP.NET Core documentation on updating useful. ASP.NET Core's examples use EF Core.
Personally I tend to go with your first approach, i.e. loading the entity, updating it and calling SaveChanges, for two reasons:
- Approach 2 means all the data in the entity would be exposed and hidden values could be altered. That is a security risk.
- Approach 2 is usually quicker, but if you have a lot of data in the entity then it could be slower, especially if your web connection is slow.
Most applications have more reads that writes, so I tend to focus on the queries unless testing shows that an update/create/delete is slow.
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow