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?

Kaenel

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

Stallion

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.

Ebba

Okeedoke. But what specifically are the problems caused with n-tier and concurrency? – Kaenel

Well the main difference other than the schema difference is that an entity with an independent association doesn't expose the foreign key in the conceptual layer. The association is maintained in a separate object. Depending on how you design your application it is more complex to pass this extra information between layers. Foreign key associations are just much easier to work with as you can just set the foreign key directly on the entity - or modify the exposed related entity/entity set. – Ebba

"Less easy to work with" in my mind doesn't necessarily translate to "avoid." The latter suggests that there are specific pitfalls. Are there any articles out there about these pitfalls? (I do have Julia Lerman's book, BTW.) – Kaenel

Isn't 'less easy' pretty much equivalent to 'more difficult'? AFAIK there is nothing that specifically prevents N-tier or concurrency. I think you might be reading a bit much into a comment - this isn't part of the official MSDN documentation is it? It's a comment on the forums I believe? My main point remains that you probably shouldn't be using these associations anyway - they have been replaced by something better - specifically because people found them confusing and hard/unnatural to work with sometimes. – Ebba

Less easy = More difficult, but it's not the same as "avoid." The comment comes from a moderator @ Microsoft, so I was giving it a lot of weight. I guess I like Independent Associations because they keep the Foreign Key Scalar out of my POCOs. For example, isn't it more confusing to have both a CustomerID and a Customer reference in your POCO? Perhaps I am misunderstanding the concept? – Kaenel