使用Entity Framework Core以多对多关系为数据库播种

Question

I created a many-to-many relationship with Entity Framework Core using this example but have a few questions:

Would it hurt anything if I add a DbSet BlogPosts to the DbContext even though they don't do it in the example?

If I don't add the DbSet to the DbContext what would be the proper way to create a Blog and then add multiple Posts to it when seeding the database. Something about the below just seems so strange. I would prefer simply creating BlogPost objects and adding them to a BlogPosts in the context.

var blog1 = new Blog() { Name = "ABC" };
blog1.BlogPosts.Add(new BlogPost { BlogId = blog1.Id, PostId = post1.Id });
var blog2 = new Blog() { Name = "123" };
blog2.BlogPosts.Add(new BlogPost { BlogId = blog2.Id, PostId = post1.Id });
var blog3 = new Blog() { Name = "XYZ" };
blog3.BlogPosts.Add(new BlogPost { BlogId = blog3.Id, PostId = post2.Id });
dbContext.SaveChanges();

Also, is it mandatory that I add a List navigation property to both the Blog and Post like in the example if I will only care about querying them from a single direction. ie Blog > Posts, don't need Post Blogs.

Answer 1

Would it hurt anything if I add a DbSet BlogPosts to the DbContext even though they don't do it in the example?

No. The explicit join entity ( BlogPost ) is entity like any other, so you can add (or not add) DbSet for it.

If I don't add the DbSet to the DbContext what would be the proper way to create a Blog and then add multiple Posts to it when seeding the database. Something about the below just seems so strange. I would prefer simply creating BlogPost objects and adding them to a BlogPosts in the context.

Even if you don't have exposed DbSet<T> property, you can always use Set<T> method to get access to the corresponding DbSet<T> :

context.Set<BlogPost>().Add(new BlogPost { BlogId = blog1.Id, PostId = post1.Id });

or use directly the Add method of the DbContext :

context.Add(new BlogPost { BlogId = blog1.Id, PostId = post1.Id });

Also, is it mandatory that I add a List navigation property to both the Blog and Post like in the example if I will only care about querying them from a single direction. ie Blog > Posts, don't need Post Blogs.

Navigation properties are not mandatory - see Single Navigation Property EF Core documentation topic. You can omit any of them. You don't even need a fluent configuration for the relationships because everything is by convention. But in case you use fluent configuration as in the example, make sure to use the WithMany() method without passing lambda/string navigation property (because you don't have it).

Answer 2

Would it hurt anything if I add a DbSet BlogPosts to the DbContext even though they don't do it in the example?

No! it wouldn't hurt! there is no problem of doing so! then you can use as follows:

context.BlogPosts.Add(new BlogPost { BlogId = blog1.Id, PostId = post1.Id });

If I don't add the DbSet to the DbContext what would be the proper way to create a Blog and then add multiple Posts to it when seeding the database.

If you don't want to expose BlogPosts as DbSet<> then you can do as follows:

context.Set<BlogPost>().Add(new BlogPost { BlogId = blog1.Id, PostId = post1.Id });

is it mandatory that I add a List navigation property to both the Blog and Post like in the example if I will only care about querying them from a single direction. ie Blog > Posts, don't need Post Blogs.

No! its not mandatory. You can do as follows:

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

}

public class Tag
{
    public string TagId { get; set; }
}

public class PostTag
{
    public int PostId { get; set; }
    public Post Post { get; set; }

    public string TagId { get; set; }
    public Tag Tag { get; set; }
}

Then in the DbContext:

class MyContext : DbContext
{
    public DbSet<Post> Posts { get; set; }
    public DbSet<Tag> Tags { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<PostTag>()
            .HasKey(t => new { t.PostId, t.TagId });

        modelBuilder.Entity<PostTag>()
            .HasOne(pt => pt.Post)
            .WithMany()
            .HasForeignKey(pt => pt.PostId);

        modelBuilder.Entity<PostTag>()
            .HasOne(pt => pt.Tag)
            .WithMany()
            .HasForeignKey(pt => pt.TagId);
    }
}