EF Code First foreign key without navigation property

ef-code-first entity-framework


Let's say I have the following entities:

public class Parent
    public int Id { get; set; }
public class Child
    public int Id { get; set; }
    public int ParentId { get; set; }

What is the code first fluent API syntax to enforce that ParentId is created in the database with a foreign key constraint to the Parents table, without the need to have a navigation property?

I know that if I add a navigation property Parent to Child, then I can do this:

    .HasRequired<Parent>(c => c.Parent)
    .HasForeignKey(c => c.ParentId);

But I don't want the navigation property in this particular case.

1/2/2014 3:23:09 PM

Accepted Answer

With EF Code First Fluent API it is impossible. You always need at least one navigation property to create a foreign key constraint in the database.

If you are using Code First Migrations you have the option to add a new code based migration on the package manager console (add-migration SomeNewSchemaName). If you changed something with your model or mapping a new migration will be added. If you didn't change anything force a new migration by using add-migration -IgnoreChanges SomeNewSchemaName. The migration will only contain empty Up and Down methods in this case.

Then you can modify the Up method by adding the follwing to it:

public override void Up()
    // other stuff...

    AddForeignKey("ChildTableName", "ParentId", "ParentTableName", "Id",
        cascadeDelete: true); // or false
    CreateIndex("ChildTableName", "ParentId"); // if you want an index

Running this migration (update-database on package manage console) will run a SQL statement similar to this (for SQL Server):

FOREIGN KEY ([ParentId]) REFERENCES [ParentTableName] ([Id])

CREATE INDEX [IX_SomeName] ON [ChildTableName] ([ParentId])

Alternatively, without migrations, you could just run a pure SQL command using


where context is an instance of your derived context class and sql is just the above SQL command as string.

Be aware that with all this EF has no clue that ParentId is a foreign key that describes a relationship. EF will consider it only as an ordinary scalar property. Somehow all the above is only a more complicated and slower way compared to just opening a SQL management tool and to add the constraint by hand.

3/13/2014 1:57:03 PM

Popular Answer

Although this post is for Entity Framework not Entity Framework Core, It might be useful for someone who wants to achieve the same thing using Entity Framework Core (I am using V1.1.2).

I don't need navigation properties (although they're nice) because I am practicing DDD and I want Parent and Child to be two separate aggregate roots. I want them to be able to talk to each other via foreign key not through infrastructure-specific Entity Framework navigation properties.

All you have to do is to configure the relationship on one side using HasOne and WithMany without specifying the navigation properties (they're not there after all).

public class AppDbContext : DbContext
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) {}

    protected override void OnModelCreating(ModelBuilder builder)

        builder.Entity<Parent>(b => {
            b.HasKey(p => p.Id);

        builder.Entity<Child>(b => {
            b.HasKey(c => c.Id);
            b.Property(c => c.ParentId).IsRequired();

            // Without referencing navigation properties (they're not there anyway)
            b.HasOne<Parent>()    // <---
                .WithMany()       // <---
                .HasForeignKey(c => c.ParentId);

            // Just for comparison, with navigation properties defined,
            // (let's say you call it Parent in the Child class and Children
            // collection in Parent class), you might have to configure them 
            // like:
            // b.HasOne(c => c.Parent)
            //     .WithMany(p => p.Children)
            //     .HasForeignKey(c => c.ParentId);



I am giving out examples on how to configure entity properties as well, but the most important one here is HasOne<>, WithMany() and HasForeignKey().

Hope it helps.

Related Questions


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