Which comes first: independent or foreign key associations?

entity-framework poco

Question

Every time I begin a new project and create my POCOs, I have an internal argument with myself. Many tutorials and code examples I've seen appear to prefer connections with foreign keys:

Association of foreign keys

public class Order
{
    public int ID { get; set; }
    public int CustomerID { get; set; } // <-- Customer ID
    ...
}

In contrast to independent relationships

Unrelated organizations

public class Order
{
    public int ID { get; set; }
    public Customer Customer { get; set; } // <-- Customer object
    ...
}

I've used independent associations while working with NHibernate in the past because they seem more object-oriented and because they give me access to the whole Customer object rather than just its ID. This enables me to, for instance, get a hold of an Order instance and then carry outOrder.Customer.FirstName without having to explicitly do a join, which is really practical.

In conclusion, these are my inquiries:

  1. Do using independent associations have any substantial drawbacks? and...
  2. What would the purpose of utilizing foreign key associations be if there were none?
1
102
3/12/2011 1:13:27 PM

Accepted Answer

Use of Entity reference is a must if you want to fully benefit from ORM.

public class Order
{
    public int ID { get; set; }
    public Customer Customer { get; set; } // <-- Customer object
    ...
}

Entity references will always be generated after an entity model has been generated from a database using FKs. You must manually add attributes representing FKs to the EDMX file if you don't wish to utilize them. At least in Entity Framework v1 when only Independent associations were permitted, this was the situation.

Foreign key association is a brand-new form of association available in Entity Framework version 4. The Order class is where the independent and foreign key associations vary the most obviously:

public class Order
{
    public int ID { get; set; }
    public int CustomerId { get; set; }  // <-- Customer ID
    public Customer Customer { get; set; } // <-- Customer object
    ...
}

As you can see, you have an entity reference as well as an FK property. Other distinctions between the two categories of relationships include:

Unrelated organizations

  • It is shown as a distinct item inObjectStateManager It's got its ownEntityState !
  • Always include members from both ends of the association while developing an association.
  • The mapping for this relationship is the same as for an entity.

Association of foreign keys

  • It is not seen as a distinct item inObjectStateManager . You must abide by certain particular guidelines as a result.
  • You don't need both ends of association to form one. Having a child entity and the PK of the parent entity is sufficient, but the PK value must be distinct. Therefore, while employing foreign keys association, you must additionally provide freshly created entities used in relations temporary unique IDs.
  • Instead of being mapped, this relationship establishes referential limitations.

Entity Data Model Wizard requires that you check the Foreign key columns should be used in the model. box if you wish to utilize foreign key association.

Edit:

I discovered that the distinction between these two kinds of relationships is not commonly understood, so I will explain it in more depth and provide my own perspective.

106
7/11/2016 9:39:59 AM

Popular Answer

Apply both. Additionally, create virtual entity references to support lazy loading. akin to this

public class Order
{
  public int ID { get; set; }
  public int CustomerID { get; set; }
  public virtual Customer Customer { get; set; } // <-- Customer object
  ...
}

This reduces the need for pointless DB lookups, enables lazy loading, and makes it simple to see or change the ID if you already know what you want it to be. Keep in mind that having both has no effect on how your table is organized.



Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow