Question

In an n-tier scenario, how is the data layer supposed to update List properties of an object in EF 4.3?

Let’s say we have this class:

public class Foo
{
  public int Id { get; set; }
  public string Name { get; set; }
  public List<Bar> Bars { get; set; }
}

This works well as far as saving/updating Id and Name, but the Bars property is ignored.

protected void SaveChanges(Foo foo)
{
  this.Database.Entry<Foo>(foo).State = GetState(foo);
  this.Database.SaveChanges();
}

Since the original context (that retrieved Foo) is no longer in memory, how should the data layer deal with saving updates to the Bars property? How does EF know which Bar items have been removed, which have been updated, and which have been added?

Note: I could loop through each Bar item and compare it to the original, but I’m guessing EF isn’t supposed to work that way. That seems tedious and incorrect.

Answer 1

How does EF know which Bar items have been removed, which have been
updated, and which have been added?

If you would write persistence yourselves how should it know about changes? I suppose you would choose one of two options:

• You would query database for current state and compare it with received state to find what has changed
• You would add some helper fields to your classes and let client tell you what has changed

In both cases you would use information about changes to generate correct SQL.

EF solves only the last point (SQL generation) but you are still responsible for telling it what has changed.