Independent EF4 Associations - Why Avoid Them?

Question

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

"Please note that independent associations should often be avoided as things like N-Tier and concurrency become more complex.

I am new to EF4 and I am creating an n-Tier web application. This sounds like an important mistake. Can someone explain to me what this means?

Answer 1

I think this is a personal preference. Initially, EF was created to use only indep. associations and aligned with the more classic ERM approach. However, most of us developers are so dependent on FK that it made life very difficult. Thus, MS provided us with FK in EF4, which meant not only the presence of FK as a property in the dependent object, but also the relations are determined by restrictions in the conceptual model, and not buried in comparisons. There are a few more relationships that you can only define using the indep association: from many to many, and with unique foreign keys. Please note: if you plan to use RIA services (not like this), then the RIA will recognize the FK associations.

So, if you prefer to use independent associations, you can still use them in EF4. They are fully supported. But, as James suggests, there are a few more pitfalls you need to know about ... things that you will need to do more explicitly because of how EF works with graphs especially. Or in the case when you just want FK, for example, you have a client identifier, but you are not an instance. You can create an order, but without this nice FID CustomerID property, you need to do additional juggling to get the Customer identifier there.

Hth

Answer 2

If you are new to EF and starting with EF4, the easy answer ignores this - you will almost certainly use foreign key associations, not independent associations.

Foreign key association is based on the relationship of foreign keys in the database, and this relationship is explicitly described in the conceptual model. Such an association is new to EF4, and I understand that this is a concession after problems faced by people with independent associations.

Strictly, if you want to separate the storage scheme and the conceptual scheme (which is a kind of EF point), you do not want your conceptual scheme to know about things such as foreign keys, such as a database (i.e. storage) concept. Earlier versions of EF followed this approach, and we call it the Independent Association.

Think of independent associations as associations that are tracked by EF without knowing the primary foreign key. EF still supports this, but they have significant flaws.

EF4 in VS2010 will use your foreign keys and create relationships with a foreign key, unless you say otherwise. In general, these works, as expected. There are some more touches - for example. around cascading deletions.

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

http://learnentityframework.com/learnentityframework/

Everything you want to know is very clearly explained.