Possible risks of turning off AutoDetectChangesEnabled in Entity Framework

Question

To improve performance of Entity Framework application there is suggestion to set AutoDetectChangesEnabled = false.

Following tutorial on MSDN states :

An alternative to disabling and re-enabling is to leave automatic detection of changes turned off at all times and either call context.ChangeTracker.DetectChanges explicitly or use change tracking proxies diligently. Both of these options are advanced and can easily introduce subtle bugs into your application so use them with care.

https://msdn.microsoft.com/en-us/data/jj556205.aspx

The last part is what concerns me.

• Can you give some most common problems that could happen with this optimization approach?
• What are good measures to prevent from unintended consequences?

Answer 1

My experience with ChangeTracking is: You should leave it on, if possible at all. For me, I had two subtle problems with ChangeTracking (For us ChangeTracking was disabled globally). Firstly, when adding/removing entities, you WILL have to set the entity state manually, because usually ChangeTracking sets the entity state to modified/added (you have to set deleted manually anyways), and this for every single entity (also those in navigation properties). Also, you have to set FK's manually in many cases.

Secondly, when EDITING related entities, you will have to call ChangeTracking or set the related entities manually - which in my experience, is quite complicated. This is because EF keeps an snapshot of related entities in its context graph, and checks this for referential integrity, not the actual related entry in your DbSet entries.

For further reference, I found an interesting article on ChangeTracking by one EF developer, Arthur Vickers.

Part 1

Part 2

Part 3 - possibly most interesting to you

Part 4

Part 5

Answer 2

Always make sure that you haven't accidentally disabled the EntityFramework Proxy Types. I had such problem and spent a plenty of time fixing it. EF's changes tracking is somehow related to this and when I disabled the changes tracking it also disabled proxy types.

EF uses it's own proxy types that mimic your types to apply it's own Lazy Loading to them. When proxy types and hence lazy loading are disabled, EF just stops loading inner entities. So if you will have a MyClass with a property myClass.MyAnotherClass it will be always null.

Personally I would recommend to leave the changes tracking enabled if you're not proficient with it. I tried to work with it being disabled, spent a few days trying to make it working and then turned it back to enabled state. It definitely affects the performance, but it's pretty intelligent and gives you a lot of advantages in exchange of that.