By using readOnly capabilities more often we are able to be more precise with our database operations, preventing future bugs. This will also speed up the code somewhat as there are fewer checks performed when not tracking objects within an entity framework context.
We currently also manually set many object to have the entity state "detached" in the code to prevent them from being updated. I believe that by refraining from tracking these objects we may sometimes be able to avoid this "hacky" behaviour, but I am cautious about doing this in this PR. We should try to make a PR though where we investigate everywhere we use this entry state statement, and instead try to not track the object.
By using readOnly capabilities more often we are able to be more precise with our database operations, preventing future bugs. This will also speed up the code somewhat as there are fewer checks performed when not tracking objects within an entity framework context.
We currently also manually set many object to have the entity state "detached" in the code to prevent them from being updated. I believe that by refraining from tracking these objects we may sometimes be able to avoid this "hacky" behaviour, but I am cautious about doing this in this PR. We should try to make a PR though where we investigate everywhere we use this entry state statement, and instead try to not track the object.