Do you mostly use this option (the default is checked) or do you uncheck it?
I found out that when I have both FK column and navigation property on my entities it results in problems with mapping tools - they might bind one or the other but almost never both.
If we were to follow the guidelines of conceptual models strictly I think those columns should never make it to properties, should they?
Hopefully many of you reply so we can get a better representation of what developers choose more often.
If we were to follow the guidelines of conceptual models strictly I think those columns should never make it to properties, should they?
Right - that's what the EF team did in the first release with .NET 3.5 SP1 - and got a ton of very negative feedback on it.
Yes, "puristically" speaking - you shouldn't be using foreign key columns directly - you should use the proper way of dealing with the referenced entity instead. But in reality, in many cases - you don't want to have to deal with the whole referenced entity, really - just setting the foreign key column will do (e.g. when importing data or many other cases).
So while yes - I agree - it's a bit of a hack at times, I do see it as a big plus that you have the option to use the foreign key column in an entity - after all, at the database level, that's what you'll be dealing with, too.
So in my opinion, and all the recommendations I've heard from colleagues who also use EF in serious work and all the blogger and EF gurus out there (like Julie Lerman who wrote the book on EF) - turn on that option, and you get the best of both worlds!