One thing that hasn't been mentioned so far is that the Entity Framework tries to keep related References and FKs in sync as much as possible. One mainline scenario is when using the tools to infer a model from a database. The second mainline scenario for creating FK Associations is creating a model from scratch, aka Model First which is new to . Here are the steps involved: And you are done you've set up an FK Association. NET 4.0 we will add support for FK Properties and FK Associations to the Entity Framework.When this synchronization occurs depends upon when the Entity Framework is notified of changes, which depends upon the type of Entity Classes involved: be they POCO with Proxies, POCO without Proxies, IPOCO or Entity Objects etc. We have added an option to choose whether "FK Associations" or "Independent Associations" are generated by default. Notice that this association doesn't need to be mapped you simply need to make sure you map all the properties of both Entities. The existing style Independent Associations will still be possible, but we expect that FK Associations will become most peoples automatic choice because they simplify so many common Entity Framework coding tasks.NET MVC controller, and is a great improvement over the code you have to write using Independent Associations.There is much more you can do with FK Associations, but these 3 samples give you a flavor of the sort of coding patterns FK Associations allow.
On the other hand customers who are concerned that have FKs in their Entities in someway pollutes their model can continue to use the type of associations we had in . Which while accurate somehow implies that associations based on FKs in Entities are "second class".
The term "Independent Association" resonates for us because they are independently mapped, whereas FK Associations need no mapping, simply mapping the Entity(Set) is sufficient.
The real reason so many customers and partners are asking for "FK Associations" is that they significantly simplify some key coding patterns.
As always we'd love to hear your thoughts on this work.
Alex James, Program Manager, Entity Framework Team, Microsoft.