Independent and Foreign key associations are two ways to model relationships in Entity framework 4. This article describes differences between them.
I'm sure there are exceptions to that, but I'm no stranger to database design and data-driven applications, and I've never created a foreign key that didn't have a purpose. Definitely not one that existed only to satisfy the database and be discarded elsewhere in my architecture.
Do you perhaps have an example you can share with us when it's preferable to ignore the fact that there's a foreign key association in the database? What do you do about error-handling in that case, and how is it preferable to catching the foreign key error raised by EF?
Thanks for the article!
I am not sure why having two types of association can be a design flaw in Entity framework. Does it not give an option for the developers to choose one over another?
I think that exposing foreign keys in EF is not needed. Foreign keys are just database way to make relations between principal and dependent record. In object oriented world we already have such construct - it is object reference which is already provided by EF through navigation properties and it should be job of persistence layer (ORM = EF) to translate these references to correct foreign keys used in the database.
But as I described in my article I believe that choice if a foreign key should be exposed in an entity as a property or not should be left to developer and not demanded by framework as happened with independent associations. The reason why I don't like foreign key associations in EF is the way how they are implemented. It is not just an extension to independent association which would allow you exposing a foreign key property. It is instead completely new feature with completely different behaviour, usage and change tracking - that is what I call design flaw because it leads to confusions and complications.