Question

First of all I am not an expert on Entity Framework.

And I have seen some piece of code in one project’s Repositories, which

• NULLs the EntityReference properties on the entity
• And keeps that EntityReference’s ID

before Saving changes of this entity.

For example it does this setting before saving Foo entity:

if (foo.Bar !=null)
{
  foo.BarID = foo.Bar.ID;
  foo.Bar = null;
}

Can this be an EntityFramework related requirement to null the EntityReference properties but using their IDs only in order to Save ?

Answer 1

No, normally that’s not a requirement. When working with attached entities for example you can change the FK property or the reference, both would work:

var foo = context.Foos.Include("Bar").Single(f => f.ID == 1);

Then…

foo.BarID = 5;
context.SaveChanges();

…would work and…

var newBar = new Bar { ID = 5 };
context.Bars.Attach(newBar);
foo.Bar = newBar;
context.SaveChanges();

…will work as well. No need to null out the reference.

The code in your question would possibly make sense if

• the foo – foo.Bar relationship is in an inconsistent/contradicting state
• and you know what is wrong

For example:

var foo = new Foo { ID = 1 };

foo.BarID = 4;
foo.Bar = new Bar { ID = 5 };

repo.UpdateFoo(foo);

And UpdateFoo is:

public void UpdateFoo(Foo foo)
{
    context.Foos.Attach(foo); // will throw an exception
    context.Entry(foo).State = EntityState.Modified;
    context.SaveChanges();
}

The Attach line would throw an exception because the FK value BarID is 4 but the referenced foo.Bar is the Bar number 5. EF does not know what is valid and will refuse to write an Update.

You could fix this problem now be adding the code in your question into the UpdateFoo method:

public void UpdateFoo(Foo foo)
{
    if (foo.Bar !=null)
    {
        foo.BarID = foo.Bar.ID;
        foo.Bar = null; // this line is not really necessary
    }

    context.Foos.Attach(foo); // no  exception anymore
    context.Entry(foo).State = EntityState.Modified;
    context.SaveChanges();
}

But this relies on the assumption that foo.Bar (with ID = 5) is valid and foo.BarID (with ID = 4) is invalid.

Generally this isn’t necessarily true, it could be just the other way around. In my opinion this snippet is a code smell which tries to fix an inconsistency in the repository layer that has actually been created in another layer (business layer or so).