EF4 Independent Associations - Why avoid them?

Question

I saw this comment on MSDN (link and link):

"Note that Independent Associations should often be avoided since things like N-Tier and concurrency becomes more difficult."

I'm new to EF4 and I'm building an n-Tier web app. This sounds like an important pitfall. Can someone explain to me what this means?

Answer 1

I think it's personal preference. Originally, EF was created to only use indep. associations and aligned with a more classic ERM approach. However, most of us devs are so dependent on FKs that it made life very complex. So MS gave us FKs in EF4 which meant not only having the FK as a property in the dependent entity but the relationships are defined through constraints in the conceptual model rather than buried in the mappings. There are still a few relationships that you can only define with an indep association: many to many and unique foreign keys. Note that if you are planning to use RIA Services (doesn't sound like it) that RIA only recognizes FK associations.

So if you prefer to leverage the independent associations you still absolutely can use them in EF4. They are totally supported. But as James suggests, there are a few more traps to be aware of...things that you'll need to do more explicitly because of the way EF works with graphs especially. Or that case where you do just want that FK , e.g., you have the ID of a customer but you don't h ave the instance. You could create an order but without that nice CustomerID FK property, you have to do some extra juggling to get that CustomerID in there.

hth

Answer 2

If you're new to EF and starting with EF4 the easy answer is ignore this - you will almost certainly be using Foreign Key Associations rather than Independent Associations.

A Foreign Key Association is backed by a foreign key relationship in the database and this relationship is explicitly described in the conceptual model. This kind of association is new to EF4 and I understand it is a concession following the issues people had with Independent Associations.

Strictly if you want to separate the storage schema and the conceptual schema (which is kind of the point of EF) you wouldn't want your conceptual schema to know about things like foreign keys as these are a database (i.e. storage) concept. Earlier versions of EF followed this approach and we have this thing called an Independent Association.

Think of Independent Associations as associations that are tracked by EF without the knowledge of the underlying foreign key. EF still supports this but they have significant weaknesses.

EF4 in VS2010 will use your Foreign Keys and create Foreign Key relationships unless you tell it otherwise. On the whole these work as you would expect. There are still some gotchas - e.g. around cascading deletes.

If you want to learn EF - I can recommend this book:

http://learnentityframework.com/learnentityframework/

Everything you want to know, very clearly explained.