Ever since POCO support was introduced in EF4 there have been two limiting restrictions on the types that can be mapped:
Types nested inside other types were not supported
Types were matched by simple names only
Some recent check-ins to the EF6 code base have lifted these restrictions to some degree when using Code First. This post describes what is now supported, what restrictions still exist, and provides some background about why things are the way they are. Continue reading →
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.