- DbContext.AcceptChanges: You want to call this method after performing inserts or updates in service operations (Web API or WCF), so that the state of each entity in the object graph is returned to Unchanged. This is done so that the entity is returned to the client is ready for additional updates.
_dbContext.ApplyChanges(product); _dbContext.SaveChanges(); product.AcceptChanges();
- ChangeTrackingCollection.MergeChanges: This method should be called on the client-side after entities are returned from an update operation. This is needed in the case where you first call GetChanges on the change tracker so that you can pass only changed items (inserts, updated and deletes) to a service update operation. After you get back the updated entities, you usually want to merge them back into entities which contain unchanged items which were not sent to the service. That’s where MergeChanges comes in. MergeChanges will combine changed and unchanged items into a single set of entities, with tracking state set to Unchanged and no cached deletes. This takes place in reverse – unchanged entities are merged into the set of entities returned by the update operation. This is needed because client-side entities are completely persistence-ignorant, and by design we don’t know which properties represent the entity key.
// Submit changes var changedOrder = changeTracker.GetChanges().SingleOrDefault(); var updatedOrder = UpdateOrder(client, changedOrder); // Merge changes changeTracker.MergeChanges(ref createdOrder, updatedOrder);
After calling MergeChanges, both createdOrder and updatedOrder point to an order entity which contains details that were not sent to the service and remain in the same state as before, as well as added, modified and deleted details that were returned from the service after having been persisted and contain database-generated values for identity and concurrency.