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!

Solution

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: