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.
I was going to write a post about when to use change-tracking proxies. But I then thought before doing that it would be useful to go over all the different types of classes that the Entity Framework supports, of which change-tracking proxies is one. So here they are, in chronological order of when they were implemented/introduced.
Imagine your app has an entity to which changes have been made and you want to reject those changes such that they won’t be saved to the database when SaveChanges is called. Using Entity Framework 4.1 you can do this by setting the state of the entity to Unchanged. For example:
context.Entry(myEntity).State = EntityState.Unchanged;