What are Independent Associations and Foreign Key Associations? [duplicate]

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?

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.

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.