Practical .NET
Potentially Save a Trip to the Database with Updates in Entity Framework
Here's a tip about how to exploit Entity Framework's change tracking mechanism to -- possibly -- eliminate a trip to the database when you update an item. But, without some additional code, you probably can't use it.
With Entity Framework, you don't need to retrieve an item from the database in order to make a change to it … but, without some change tracking mechanism, you probably won't get the update you want.
For example, if you want to update an existing Customer object you don't have to retrieve the existing version of the object. Instead, you can simply create that object, change the properties you want to update, and call Entity Framework's SaveChanges method. You need to attach your new object to its collection before you make significant changes to the object's properties, though, as this code does before updating the customer's FirstName:
Dim cust As New Customer
cust.CustId = 1
db.Customers.Attach(cust)
cust.FirstName = "Jan"
db.SaveChanges()
If you change the object's properties before you attach you attach it then Entity Framework won't see your changes and won't update the corresponding columns in the table. In my code, you can see that I set the property that maps to the Customer table's primary key column before I attach my object. I did that because I don't want to update the primary key column – I'm only setting that property so that Entity Framework can find the row to update.
Another way of handling updates without retrieval is to set the Customer object's state to Modified. However, if you do that then Entity Framework can assume that you've changed all the properties on the object. In my example that isn't going to end well because I've left most of the properties unset – the resulting SQL Update statement might set all of the columns in the Customer table to the default values of their corresponding properties.
Presumably I only set the FirstName property because I had some change tracking mechanism that let me know that was the only value that had changed. If I had set all of the properties on the Customer object (and used Attach) then the resulting SQL statement would update all of the columns in the table. That may not strike you as a bad thing but it means you could overwrite the changes of some other user who retrieved the row at the same time as you did but saved their changes before you. That's not going to end well, either.
If you're interested in what such a change tracking application looks like, I've written a column about that. But if it strikes you as more work than you're interested in, it might be easier just to take the time to retrieve the original Customer object and update its properties.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.