Entity Framework 6: Adding child object to parent's list vs. setting child's navigation property to parent

Question

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.

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.

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();
        }

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();
        }

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?

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.

Answer 1

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.

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?

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.).

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