Should I keep foreign keys in sync with links when using POCOs

Question

I see many examples of using EF code first with POCOs that show something like this:

public class Post { public int PostId { get; set; } public string Title { get; set; } public string Content { get; set; } public int BlogId { get; set; } public virtual Blog Blog { get; set; } } 

Now let's look at the Blog property. Shouldn't it be like this:

 private Blog blog; public virtual Blog Blog { get { return blog; } set { blog = value; if (blog != null) { BlogId = blog.BlogId; } } } 

I mean, since you are already "polluting" your model with a foreign key, shouldn't you synchronize it with the link? Or you should not rely on BlogId to read data in any way (for example, how do you want to know if a specific BlogId is on the list). Or maybe there is a magical property on a DbContext (e.g. KeepForeingKeysPropertiesSyncronizedWithReferences ) that does this for me, and am I the only sad programmer that this bothers? Or am I paranoid? (also, sorry for my poor english)

EDIT Sorry for that - it really was a stupid question. Stefan is right, EF really does it for you. I did not see this because the links that I was following were loaded using AsNoTracking() . Only in this state will you have a link with an identifier, and the foreing key field will be 0. While you pass the link that is already in context, it should work.

Answer 1

You do not need to do this as such, EF does it for you.
If you set the independent association property, EF will synchronize the foreign key property to reflect your change and vice versa. This does not happen right away, automatically automatically, you think that it happens after calling SaveChanges, but I'm not sure.
If you want to know why some people use the foreign key property: this is more convenient in individual applications, such as web applications. When you need to scale your application, it can also help increase productivity (read this in a recent MS blog post).
Basically, you only need to do it yourself if you mix and match; when in one way you use the independent association property and in the other you use the foreign key property.

Answer 2

Database The first code is created.

You seem to give, otherwise you will get the following error.

A violation of a referential integrity constraint has occurred: a property values ​​that define referential constraints are incompatible between the main and dependent objects in the relation.

The principle is your Post object, a dependent Blog object.

when you try to attach your unallocated context, release POCO to the EF 4.1 DBContext context:

 using (TransactionScope scope = new TransactionScope()) using (ITAMdbContext db = new ITAMdbContext()) { db.Entry(post).State = System.Data.EntityState.Unchanged; // error here db.Entry(post).State = System.Data.EntityState.Modified; db.SaveChnages(); 

This error is resolved ..

 using (TransactionScope scope = new TransactionScope()) using (ITAMdbContext db = new ITAMdbContext()) { post.BlogId = post.Blog.BlogId; // fix the broken FK value, EF will not do this for // you, it does not know if post.BlogId or the post.Blog.BlogId should be chosen. db.Entry(post).State = System.Data.EntityState.Unchanged; db.Entry(post).State = System.Data.EntityState.Modified; db.SaveChnages(); 

do it your own way if your POCO objects are not automatically generated.

the reason you set the post to Unchanged, and then set it to Modified, because the first property is Entry (). State set on the object will cascade the same state to all child objects! horrible, but it seems to work. then when you call it again, it only changes the post object. This stops the children that are being modified or added.

EDIT: it is no longer required, it is made for you