Change tracking in poco objects can be accomplished in two ways. If you mark your properties as virtual, EF will create a proxy object for your entity and any property changes will be notified to the ObjectStateManager immediately. However bare bone poco class has no mechanism to inform ObjectStateManager of changes occurring. When poco object is attached to the context, EF will take a snap shot of the current property values and when DetectChanges is called either explicitly or implicitly when SaveChanges occurs, EF will walk the object graph looking for changes that have occurred and modify the state of the object correctly in the state manager. This form of change tracking is called Snap Shot based change tracking where EF takes a snap shot of the original object and then a modified object to find the difference. Let’s look at example of a model consisting of Employee entity with Name property as complex type.
The POCO class for the above entity is shown below.
In the above class we are using virtual keyword on every property of our poco class.Since the above class meets the proxy rules and proxy creation is enabled, EF will create a proxy object for employee entiy and notify changes as they are made to the to ObjectStateManager as they occur. There is one caveat to this. If your object has complex type properties and you modify one of the properties, EF will use snap shot based change tracking meaning changes wont be in sync with the ObjectStateManager. However if you completely swap out the complex type with a brand new instance, it will use change tracking proxy.
In code and screen shot above, you can see that we modified one of the complex type property and queried for the state of the entity in the ObjectContext, it was still set to UnChanged because it uses snap shot based change tracking. However when we modified a scalar property on the Employee entity, the object state immediately reflected Modified as shown on the screen shot capture.
What’s interesting is, although Complex Type does not take advantage of notification based change tracking, you still have to use virtual keyword for the rest of entity to benefit from the proxy notification. Failing to do so, would prevent EF to create a proxy object for employee entity because it no longer follows the proxy rules. Once again one of the proxy rule is, all properties must be marked as virtual regardless if they care complex type, references, collection or scalar types.