In the last few posts we saw how to hide use of the join entity from two entities with a many-to-many relationship. This post doesn’t add any additional functionality, it just abstracts some of what we saw so it can be re-used more easily.
It is common for a single parent entity to be related to many child entities. This relationship may be required or optional. A required relationship means that the child cannot exist without a parent, and if the parent is deleted or the relationship between the child and the parent is severed, then the child becomes orphaned. In such situations it is often useful to have the orphaned child automatically deleted. Continue reading
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.
Since EF4 it has been possible to map foreign key columns to properties of entity classes. But is it really a good idea to do this? In this post I’ll explain the reasons for keeping foreign keys out of your object model and contrast that with how mapping foreign keys may make your life easier.