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.
EF Code First is great and I use it all the time, even when mapping to existing databases. However, if your intention is to use a Database First flow, then it’s important that you don’t start to use Code First unintentionally. If you do, then you might end up with exceptions like those described in this Stack Overflow question.
There’s a fairly common misconception that EF4 was the fourth version of the Entity Framework. It’s a reasonable assumption to make, but actually EF4 was only the second released version of EF. It was called EF4 not because it was version 4, but because it was released as part of .NET 4.0.
You may also have heard the EF4.1 builds on top of EF4 without changing the “core” libraries. What does this mean? Read on to find out more and dazzle your friends with EF trivia.