ASP.NET MVC: Repository pattern high concurrency updates

Question

I'm writing an app that we may be switching out the repository later (currently entity framework) to use either amazon or windows azure storage.

I have a service method that disables a user by the ID, all it does is set a property to true and set the DisabledDate. Should I call to the repository, get that user, set the properties in the service, then call to the save function in the repository? If I do this, then thats 2 database calls, should I worry about this? What if the user is updating the profile at the same time the admin is calling the disable method, and calls the user calls the save method in the repository (which currently holds false for the IsDisabled property?) Wouldn't that set the user back to being enabled if called right after the disabled method?

What is the best way to solve this problem? How do I update data in a high concurrent system?

score 1 · Answer 1 · answered Dec 23 '10 at 05:02

1

As long as you know the id of the entity you want to save you should be able to do it by attaching the entity to the context first like so:

var c = new Customer();
c.Id = someId;
context.AttachTo("Customer", c)
c.PropertyToChange = "propertyValue";
context.SaveChanges();

Whether this approach is recommended or not, I'm not so sure as I'm not overly familiar with EF, but this will allow you to issue the update command without having to first load the entity.

answered Dec 23 '10 at 05:02

lomaxx

113,627
57
144
179

This means my logic of disabling the user will be in the repository, not in the service layer? – Shawn Mclean Dec 23 '10 at 05:04
No, the logic will still be in the service layer, just put a method on your repository userRepo.DisableUser(userId). – lomaxx Dec 23 '10 at 05:07
@Shawn Mclean - pass through the entity to the Repository. Then use what @lomaxx has suggested - but attach a "stub" to the graph, then use "ApplyCurrentValues" to override the stub with the entity your passing through. Requires only 1 call. – RPM1984 Dec 23 '10 at 05:08
@RPM1984, could you make that an answer? I dont quite understand that. – Shawn Mclean Dec 23 '10 at 05:11
Oh, I understand. Pass the model up to the repository instead of the ID. So I would set the ID and the other properties on the model before calling the repository. – Shawn Mclean Dec 23 '10 at 05:14
yep... exactly. Sorry, my comment was a little confusing. – lomaxx Dec 23 '10 at 05:16
@Shawn Mclean - answer added. – RPM1984 Dec 23 '10 at 05:21

score 1 · Accepted Answer · edited Mar 21 '20 at 23:25

CustomerRepository:

// Would be called from more specific method in Service Layer - e.g DisableUser
public void Update(Customer c)
{
   var stub = new Customer { Id = c.Id }; // create "stub"
   ctx.Customers.Attach(stub); // attach "stub" to graph
   ctx.ApplyCurrentValues("Customers", c); // override scalar values of "stub"
   ctx.SaveChanges(); // save changes - 1 call to DB. leave this out if you're using UoW 
}

That should serve as a general-purpose "UPDATE" method in your repository. Should only be used when the entity exists.

That is just an example - in reality you should/could be using generics, checking for the existence of the entity in the graph before attaching, etc.

But that will get you on the right track.

ASP.NET MVC: Repository pattern high concurrency updates

2 Answers2

CustomerRepository:

Linked