Understanding EF Core Relationships: Why Include public int BlogId { get; set; } and public Blog Blog { get; set; } in the Post Class?

I have been working with Entity Framework Core and I'm trying to understand relationships better. I have two classes, Blog and Post, which define a one-to-many relationship where a Blog contains multiple Post entities.

Here are the simplified class definitions:

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual Uri SiteUri { get; set; }

    public ICollection<Post> Posts { get; }
}

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
    public DateTime PublishedOn { get; set; }
    public bool Archived { get; set; }

    public int BlogId { get; set; }
    public Blog Blog { get; set; }
}

My confusion arises from the presence of the

public int BlogId { get; set; }

and

public Blog Blog { get; set; } 

properties in the Post class. As far as I understand, these two properties are not directly migrated to the database as columns. Why are they necessary in this relationship definition?

I'm considering asking this question on Stack Overflow to clarify my understanding. Could someone provide an explanation for including these properties, their roles in the relationship, and how they enhance the Entity Framework Core experience?

Any insights would be greatly appreciated!

Thank you in advance for your help!

> As far as I understand, these two properties are not directly migrated to the database as columns. Why are they necessary in this relationship definition?

BlogId is added as a column. It will be used to setup the relationship and will be used as foreign key (in relational database). Actually specifying BlogId is not required, just adding:

public Blog Blog { get; set; } 

Is enough, EF Core will create corresponding columns (but personally I prefer to expose it due to it being useful in some cases).

For example in SQL Server it should result in something like the following:

CREATE TABLE [Posts] (
    [Id] int NOT NULL IDENTITY,
    [Title] nvarchar(max) NULL,
    [Content] nvarchar(max) NULL,
    [PublishedOn] datetime2 NOT NULL,
    [Archived] bit NOT NULL,
    [BlogId] int NOT NULL,
    CONSTRAINT [PK_Posts] PRIMARY KEY ([Id]),
    CONSTRAINT [FK_Posts_Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [Blogs] ([Id]) ON DELETE CASCADE);

> Why are they necessary in this relationship definition?

In theory you can omit both properties and setup the relationship via fluent interface, but in general having the navigation property is considered a good practice, so you will simplify your life and use them instead of writing "manual" joins to filter or load related data. For example the following:

    var blogs = context.Blogs
        .Include(blog => blog.Posts)
        .ToList();

Should generate appropriate SQL with joins and fill the needed data for the ease of use.

Sources/read also:

• Introduction to relationships

• Relationship navigations

• One-to-many relationships

• Loading Related Data

First of all you should add the annotation [ForeignKey(nameof(this.Blog))
] on BlogId or describe the relation ship with fluent API on modelCreating from your context.

By doing this the ef will create the relatioship on the database if you are using the code first approach.

Then the Blog property is called as a navigation property and is the way to tell ef to map the related entity both ways.

So in your query:

Var posts = ctx.Post.Include(x => x.Blog).ToList() you will join the blog to the post.

Whenever you access a post object, lets say:

posts[0]

You will have a direct access to your blog objects of this post by doing this:

posts[0].Blogs which is a list o blogs

And thats the navigation property and the reason why is there.

I suggest that you start reading a book for ef for beginners before starting coding so you have a better understanding for what the ef it is and the relation it has with the db!!