实体框架 6:将子对象添加到父列表与将子对象的导航属性设置为父对象

问题描述

我有一个现有的数据库，其中包含两个表 MailServers 和 MailDomains.MailDomains 的外键列 MailServerId 指向 MailServers 中的 Id 主键列.所以我们这里是一对多的关系.

I have an existing database with two tables MailServers and MailDomains in it. MailDomains has the foreign key column MailServerId pointing to the Id primary key column in MailServers. So we have a one-to-many-relationship here.

我关注 这篇文章并通过实体数据模型向导中的数据库优先代码"模型.这产生了以下两个 C# 类:

I followed this article and created my Entity Framework POCOs via the "Code first from database" model in the Entity Data Model Wizard. This produced the following two C# classes:

public partial class MailServer
{
    public MailServer()
    {
        MailDomains = new HashSet<MailDomain>();
    }

    public int Id { get; set; }

    public virtual ICollection<MailDomain> MailDomains { get; set; }
}



public partial class MailDomain
{
    public MailDomain()
    {
    }

    public int Id { get; set; }

    public string DomainName { get; set; }

    public int MailServerId { get; set; }
    public virtual MailServer MailServer { get; set; }
}

现在我的问题是以下两种在数据库中创建和插入新对象的方法之间是否有任何区别.

Now my question is whether there is any difference between the following two approaches of creating and inserting new objects to the database.

方法(A):将新子添加到父列表中:

Approach (A): Adding new child to the parent's list:

        var mailServer = new MailServer();
        var mailDomain = new MailDomain() {
            DomainName = "foobar.net",
        };
        mailServer.MailDomains.Add(mailDomain);

        using(var context = new MyContext){
            context.MailServers.Add(mailServer);
            context.SaveChanges();
        }

方法(B):将子级的导航属性设置为父级:

Approach (B): Setting the child's navigation property to the parent:

        var mailServer = new MailServer();
        var mailDomain = new MailDomain() {
            DomainName = "foobar.net",
            MailServer = mailServer,
        };

        using(var context = new MyContext){
            context.MailDomains.Add(mailDomain);
            context.SaveChanges();
        }

我还假设在方法 (A) 中，新的 MailDomain 实例会自动添加到集合 context.MailDomains 中，而在方法 (B) 中，新的 MailServer 实例自动添加到集合 context.MailServers.这是正确的还是我必须手动执行?

I also assume that in approach (A) the new MailDomain instance is automatically added to the collection context.MailDomains while in approach (B) the new MailServer instance is automatically added to the collection context.MailServers. Is that correct or do I have to do that manually?

我的问题是:这两种方法可以互换吗?它只是让我感到困惑，在数据库中只有一个属性/列要设置(即 MailDomains 中的外键)，而在 C# 代码中有两个属性(每个类中一个)可能是修改.

So again, my question is: are the two approaches interchangeable? It just confuses me that in the database there is only one property/column to set (namely the foreign key in MailDomains) while in the C# code there are two properties (one in each class) that could be modified.

推荐答案

是的，这两种方法是可以互换的.这允许您从 MailServer 或 MailDomain 的角度创建对象图并将其保存到数据库.

Yes, the two approaches are interchangeable. This allows you to create and save your object graph to the database from either the perspective of the MailServer or the MailDomain.

如果您执行代码优先，则可以选择删除不需要的属性和映射.

If you do code-first, you have the option of removing the properties and mappings if they're not needed.

我还假设在方法 (A) 中，新的 MailDomain 实例是在方法 (B) 中自动添加到 context.MailDomains新的 MailServer 实例会自动添加到 context.MailServers.这是正确的还是我必须手动执行?

I also assume that in approach (A) the new MailDomain instance is automatically added to context.MailDomains while in approach (B) the new MailServer instance is automatically added to context.MailServers. Is that correct or do I have to do that manually?

这取决于您所说的添加到上下文中"是什么意思.如果你的意思是:当你持久化时它是否会自动保存到数据库中，答案是肯定的.使用像 EF 这样的 ORM 的一大好处是它可以自动处理保存完整的对象图(以及同步 PK/FK 关系等).

It depends what you mean by "added to the context". If you mean: does it automatically get saved to the database when you persist, the answer is yes. One of the big benefits to using an ORM like EF is that it handles saving a full object graph automatically (and syncing PK/FK relations, etc.).

如果您的意思是:实体在保存之前是否可以通过上下文访问，我不这么认为(我不是 100% 确定).

If you mean: will the entity be available via the context before saving, I don't think so (I'm not 100% sure).