20

Possible Duplicate:
Code First: Independent associations vs. Foreign key associations?

In EF 4 or EF 5 Code First, what is an "independent association" and what is a "foreign key association", as used on MSDN or Foreign Key vs. Independent Relationships - is there improvement with Entity Framework 5? (emphasis added):

2.4.1 Using Foreign Key Associations to reduce view generation cost

We have seen a number of cases where switching the associations in the model from Independent Associations to Foreign Key Associations dramatically improved the time spent in view generation.

So -- now I know which to use. If only I knew what they were and how one would convert to it! My question, then, is, how would you define those terms? What fluent/annotations/conventions invoke each?

Community
  • 1
  • 1
Scott Stafford
  • 43,764
  • 28
  • 129
  • 177
  • @LadislavMrnka: I studied that question first but found it not that clear on the definitions and of a slightly different thrust -- namely: WHY to use one or the other, rather than simply defining WHAT they were. – Scott Stafford Sep 26 '12 at 18:32
  • You should modify your question because at the moment it asks about what are these associations and how to create them and that is exactly what linked question provides. If you also want to know why to use each of them put it to your question directly. – Ladislav Mrnka Sep 26 '12 at 18:42
  • I humbly beg to differ. He states his question at the end: "Are there any significant disadvantages in using independent associations? and... If there aren't any, what would be the reason of using foreign key associations at all?" In other words -- "why do I use each?" All I want to know is what the two phrases mean and how to make something be one or the other. – Scott Stafford Sep 26 '12 at 19:20
  • I did try to clarify my WHAT further, though, let me know if that helps. – Scott Stafford Sep 26 '12 at 19:26
  • @ScottStafford: I thoroughly agree with your comments above, I had the same feeling after going through the other question's link. – Veverke Jul 07 '16 at 14:22

2 Answers2

36

Just my opinions about WHY to use independent or foreign key associations:

Independent associations

Pros:

  • This is correct way to go in object oriented world. In object oriented world we are using references inside our aggregates, not some magic keys.

Cons:

  • With pure POCO you don't know if principal relation is really NULL or just not loaded because in both cases your reference is null. You must ask context to differ between those two nulls. This was not a problem with heavy EntityObject base entities where every navigation property to principal entity was paired with another property suffixed Reference providing some additional details about the relation.
  • EF's way to manage independent associations is quite complex especially when it comes to attaching detached object graphs. Each independent association has its own state and it can never be in Modified state. Every modification always consists of setting old relation as deleted and creating new relation as added - this is a real mess when you try to use it.
  • It was reported that independent associations slow down view generation during EF's initialization (or during view pregeneration) significantly.
  • Independent association can be much harder to use in data-binding scenarios where you need to bind just foreign key.

Foreign key associations

Pros:

  • Simple. Key properties are easy to manage and they solve all issues with independent associations - no state for foreign associations, direct data-binding, immediate visibility if relation exists (key is not null), etc.

Cons:

  • They are conceptually wrong and offering them in EF was a big step back from object world to relational world. I still believe that correct solution was improving or changing the way how independent associations are handled even if it could cause huge breaking changes between EFv1 and EFv4. I also don't like current situation where we have two types of associations with completely different behavior. There should be only one type with well defined behavior and optional foreign key properties exposed on entity.

This difference matters only for one-to-many associations because one-to-one are always Foreign key associations and many-to-many are always independent associations.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • 6
    +1 for last sentence. this was not obvious to me beginning. – parliament Mar 24 '13 at 20:41
  • @Ladislav Mrnka - This is a great answer. I was wondering if there is any significant updates to this answer as EF is out in a v6? I am current designing a completely new web-app and I am struggling on what way I should go. – janhartmann Jul 10 '14 at 05:57
  • @meep: I'm not working with EF any more but I don't think anything has changed in EF6 - you still have these two options. Using foreign-key associations can reduce complexity of some development tasks when working with detached objects and that can happen in web applications frequently. – Ladislav Mrnka Jul 10 '14 at 12:48
29

Foreign Key Association is where you have a foreign key property in your model in addition to the corresponding Navigation Property. Independent Association is when you have a foreign key column in your database but the foreign key property corresponding to this column is not in your model - i.e. you have a NavigationProperty but there is no foreign key property that would tell you what the ID value of the related property is without actually going to the related property.

Here is an example of a model with an Independent Association (notice that the Dependent does not have a foreign key - just navigation property):

public class Dependent
{
    public int Id { get; set; }

    [Required]
    public Principal PrincipalEntity { get; set; }

}

public class Principal
{
    public int Id { get; set; }
    public ICollection<Dependent> DependentEntities { get; set; }
}

public class MyContext : DbContext
{
    public DbSet<Dependent> Dependents { get; set; }
    public DbSet<Principal> Principals { get; set; }
}

And here is an example of the same model but with the ForeignKey Association (notice the PrincipalEntity_Id property and the [ForeignKey()] attribute):

public class Dependent
{
    public int Id { get; set; }

    public int PrincipalEntity_Id { get; set; }

    [Required]
    [ForeignKey("PrincipalEntity_Id")]
    public Principal PrincipalEntity { get; set; }

}

public class Principal
{
    public int Id { get; set; }
    public ICollection<Dependent> DependentEntities { get; set; }
}

public class MyContext : DbContext
{
    public DbSet<Dependent> Dependents { get; set; }
    public DbSet<Principal> Principals { get; set; }
}

Note that your database won't change - the underlying database always had the column for the foreign key but with the independent association it was not exposed.

With foreign key associations you can update the relationship just by changing the value of the foreign key. This is handy if you know the value because you don't need to load the entity you want to update the navigation property to.

Pawel
  • 31,342
  • 4
  • 73
  • 104
  • This and the other answers do not seem to touch performance concern. However, according to section [**2.2 Factors that affect View Generation performance**](https://msdn.microsoft.com/en-us/data/hh949853) from an MSDN article, using Independent Association seems to increase the cost of View Generation over Foreign Key associations – Veverke Jul 07 '16 at 14:33
  • I don't think it is really noticeable anymore with improvements made to view generation in recent releases. – Pawel Jul 07 '16 at 16:35