CODEWITHSUNDEEP
c#asp.net-mvcentity-frameworkef-code-first
anemaria20
anemaria20

Reputation: 1728

Why have a foreign key in a class in Entity Framework?

Say I have 2 classes: Ninja has-many NinjaEquipment. Inside NinjaEquipment, I have: public Ninja Ninja { get; set; }. I've seen some people also include a reference to the foreign key, such as: public int NinjaID { get; set; }. What's the point of doing this? Isn't a simple Ninja reference enough if I want to get to the "parent" of one-to-many relationship?

Upvotes: 6

Views: 3135

Answers (4)

Luke
Luke

Reputation: 23680

You're right, you don't need to add the ID column as a property within your models, Entity Framework is intelligent enough to generate your foreign key column for you and your relationship between the tables in most cases.

Personally, when I was setting up my website, I had an existing database that I wanted to use with Entity Framework, so I needed the control. I added the foreign key properties myself and set up the mappings between the two tables using the Fluent API because I had foreign key columns with names that didn't match with the Entity Framework convention.

For example:

public class NinjaEquipmentMap : EntityTypeConfiguration<NinjaEquipment>
{
    public NinjaEquipmentMap
    {
        // Fluent API examples:

        // Describes the relationship between the entities 
        // and the property to use as the foreign key.
        this.HasRequired(t => t.Ninja)
            .WithMany(c => c.NinjaEquipment)
            .HasForeignKey(c => c.NinjaId);

        // I can specify a relationship using a property name
        // that existed in my existing database.
        this.HasRequired(t => t.Ninja)
            .WithMany(c => c.NinjaEquipment)
            .HasForeignKey(c => c.SuperNinjaId);
    }
}

If you were creating a new database from scratch, it may be acceptable to allow Entity Framework to do the leg work and generate the columns for you.

Another reason that I can think of is that you may want to expose the foreign key value in your model.

// 
// BEFORE
// 
var ninjaEquipment = dbContext.Set<NinjaEquipment>().Find(1);

// We have to load the Ninja record to find out the related Ninja ID
var ninjaId = ninjaEquipment.Ninja.Id;

// 
// AFTER
// 
var ninjaEquipment = dbContext.Set<NinjaEquipment>().Find(1);

// Find out the Ninja equipment ID without having to load the Ninja
var ninjaId = ninjaEquipment.NinjaId;

I personally like the control :o)

Upvotes: 1

ken2k
ken2k

Reputation: 48975

It's generally useful when you need the ID of the child/parent item: for example if you have NinjaID within NinjaEquipment, you won't need to lazy-load (or include) the Ninja navigation property.

This results in simpler requests, i.e. with less SQL JOINs.

Upvotes: 0

Grizzly
Grizzly

Reputation: 5943

What's the point of doing this?

I believe this is a difference between Foreign Key's and Navigation Properties.

Navigation properties provide a way to navigate an association between two entity types. Every object can have a navigation property for every relationship in which it participates. Navigation properties allow you to navigate and manage relationships in both directions, returning either a reference object (if the multiplicity is either one or zero-or-one) or a collection (if the multiplicity is many). You may also choose to have one-way navigation, in which case you define the navigation property on only one of the types that participates in the relationship and not on both.

It is recommended to include properties in the model that map to foreign keys in the database. With foreign key properties included, you can create or change a relationship by modifying the foreign key value on a dependent object. This kind of association is called a foreign key association. Using foreign keys is even more essential when working with N-Tier applications. Note, that when working with 1-to-1 or 1-to-0..1 relationships, there is no separate foreign key column, the primary key property acts as the foreign key and is always included in the model.

When foreign key columns are not included in the model, the association information is managed as an independent object. Relationships are tracked through object references instead of foreign key properties. This type of association is called an independent association. The most common way to modify an independent association is to modify the navigation properties that are generated for each entity that participates in the association.

This information can be found at this source.

Upvotes: 2

Abdurahman Almatrodi
Abdurahman Almatrodi

Reputation: 65

It is the same as you design your tables in the database. You must have a foreign key to have the relations between them. This is what Navigation Properties depends on. for more reading https://msdn.microsoft.com/en-us/data/jj713564.aspx

Upvotes: 0

Related Questions