By default, EF Core uses snapshot change tracking. However, if entity types implement INotifyPropertyChanged and optionally INotifyPropertyChanging, then EF can use these notifications to avoid the overhead of creating snapshots and detecting changes.
In parts 1, 2, and 3 of this series we looked at fairly normal, if occasionally advanced, uses of DetectChanges. In this post we’re going to look at some corner cases around complex types and binary properties. While these are corner cases its still worth knowing about them so they don’t catch you out if you ever run into them. Continue reading →
In parts 1 and 2 of this series we looked at what DetectChanges does and why the context calls DetectChanges automatically. In this part we’ll look at how automatic calls to DetectChanges can be switched off and what you then need to do differently in your code.
Part 1 of this series on DetectChanges described why DetectChanges is needed to discover the changes that have been made to POCO entities. This part will expand on that information and look at when it is important for the context to know about these changes. This will provide the basis for detailing when the context calls DetectChanges automatically. Continue reading →
Entity Framework change tracking is often something that doesn’t require too much thought from the app developer. However, change tracking and the DetectChanges method are a part of the stack where there is a tension between ease-of-use and performance. For this reason it can be useful to have an idea of what is actually going on such you can make an informed decision on what to do if the default behavior is not right for your app.