次の方法で共有

Change Tracking Mechanisms

  • [アーティクル]

I continually find myself delaying posts on topics like this because I’d like to do a better job by the material, but given my harried schedule, it seems useful to at least get something out there whenever I can in the hope that it will be useful to someone. If something is unclear or generates questions, don’t hesitate to ask.

Recently a fellow Microsoftie posted a question on an internal discussion list asking about building an n-tiered, stateless application. In particular, they were wondering about how the Entity Framework computes update statements. They assumed that it keeps a copy of the original values and were concerned that such a mechanism would be incompatible with their target architecture. Here’s a copy of the relevant parts of my response:

From: Daniel Simmons
Sent: Saturday, March 24, 2007 10:03 AM
Subject: RE: Dynamic updates

 

Actually, the way the entity framework does this by default is to require notifications of changes from the entity objects to a framework class called the state manager which then keeps track of which properties have been changed. The original values are copied only on demand. When updates happen, those original values are used in talking to the server only if the changed properties are marked as “concurrency tokens”. That is, for any concurrency token columns, when the framework is creating an update statement it will include a check to verify that the row in the database still has the original value, and if not it will raise an exception to notify the program that someone else has changed the row in the database. It’s also true that the entity framework doesn’t absolutely require notifications from the property setters, you can also determine what’s modified in the application code and call an explicit method on the framework to indicate which properties are changed (but then the framework will only have a record that the property is modified, it won’t have an original value). This means a few things to you:

1) You can choose a variety of concurrency management policies including: last update wins (mark nothing as a concurrency token so all updates just go through unconditionally—this also means that you don’t have to track original values at all if you want to use the explicit method to indicate which properties have changed), pick a particular column such as a timestamp or version as the indicator of concurrency (then you only have to make sure that its original value is maintained accurately), mark every property as a concurrency token (so any update to the row by other app code will cause a concurrency violation—this also means you need to track all original values and that update statements are less efficient because they send over the wire all original values as well as all current values).

2) You can either follow the default model that codegen uses where notifications cause the framework to track all updates (simplest codel for 2-tier rich client apps or other cases where all original values are known and changes are just made on top of those original values), or you can more explicitly manage original values and change tracking. In an asp.net application with a form to update the values of an entity, for instance, you could have a page load routine which queries the database, binds the original entity values into the form controls and then serializes either the entire entity or just the critical concurrency token properties into viewstate. When the save button click call-back is made, a new context can be created and either a deserialized copy of the original entity attached or a synthesized version of that which just has the original concurrency values (and the key). Then the values that were updated on the form can be set onto that entity which causes the framework to become aware of just which properties need updated as well as original values for those properties that you care about (so that concurrency checks can be made).

I know this covers a lot of ground, and I’ve sort of just been rambling, but maybe this gives you a flavor of the kinds of options you have with the entity framework.

Comments

  • Anonymous
    March 28, 2007
    Pingback from http://oakleafblog.blogspot.com/2007/03/orcas-edm-wizard-and-designer-previewed.html

  • Anonymous
    March 30, 2007
    David Simmons explained how the 'disconnected mode' works today in Entity Framework (and as far

  • Anonymous
    March 30, 2007
    Udi replied to my post , I was going to answer in his blog but it was too long. This is not about using

  • Anonymous
    April 02, 2007
    Recently, Andres Aguiar started a discussion between him and Udi Dahan about change tracking in the upcoming

  • Anonymous
    April 03, 2007
    Frans has finally pulled the discussion out of SOA land back to DB land. With his post " Why change-tracking

  • Anonymous
    September 26, 2007
    I had someone email me a question today about POCO, IPOCO, persistence ignorance and the EF, and I responded

  • Anonymous
    February 25, 2008
    hello, Maybe you want to checkout the PostSharp4EF for POCO support -> http://www.codeplex.com/efcontrib