Changing Entity’s State in Entity Framework 4.1

dbcontextentity-framework-4.1

Let say we have a Customer object which has an Order object. The Order object has OrderDetail object.

Customer oCustomer 
using(var context = new MyContext)
{
oCustomer = context.Include("Order.OrderDetail").Find(1);
}
oCustomer.Name ="blah blah";
oCustomer.Order.Description = "blah blah";
oCustomer.Order.OrderDetail.Quantity = 10;

Now when I change the state of Customer as following:

using(var context = new MyContext)
{
    context.Entry(oCustomer).State = EntityState.Modified.
    context.SaveChanges();
}

This saves only oCustomer object and not the Order and OrderDetail that are in oCustomer. Since context.Entry(oCustomer).State = EntityState.Modified changes state of oCustomer only and not the Order and OrderDetail. Currently, I have to change the state of each entity in the ObjectGraph manually so that the changes are saved. Is there any way to change the state of whole ObjectGraph instead of just the parent entity? Is there any extension method or any other way out to do that?

Best Answer

Since you are cutting the link between the context and the entity, no. It can not automagically know all the entries are in the modified state.

You could create your own extension method (or add it to your derived object context class) to walk over all the properties and check if they are mapped in the configuration and if so, set them to modified.

I assume you're working in a disconnected environment, the easiest way is to redo all the changes you've don in the other process. Load the entity from the db again, and populate the properties and call save changes.

Related Solutions

How Should I Declare Foreign Key Relationships Using Code First Entity Framework (4.1) in MVC3

If you have an Order class, adding a property that references another class in your model, for instance Customer should be enough to let EF know there's a relationship in there:

public class Order
{
    public int ID { get; set; }

    // Some other properties

    // Foreign key to customer
    public virtual Customer Customer { get; set; }
}

You can always set the FK relation explicitly:

public class Order
{
    public int ID { get; set; }

    // Some other properties

    // Foreign key to customer
    [ForeignKey("Customer")]
    public string CustomerID { get; set; }
    public virtual Customer Customer { get; set; }
}

The ForeignKeyAttribute constructor takes a string as a parameter: if you place it on a foreign key property it represents the name of the associated navigation property. If you place it on the navigation property it represents the name of the associated foreign key.

What this means is, if you where to place the ForeignKeyAttribute on the Customer property, the attribute would take CustomerID in the constructor:

public string CustomerID { get; set; }
[ForeignKey("CustomerID")]
public virtual Customer Customer { get; set; }

EDIT based on Latest Code You get that error because of this line:

[ForeignKey("Parent")]
public Patient Patient { get; set; }

EF will look for a property called Parent to use it as the Foreign Key enforcer. You can do 2 things:

1) Remove the ForeignKeyAttribute and replace it with the RequiredAttribute to mark the relation as required:

[Required]
public virtual Patient Patient { get; set; }

Decorating a property with the RequiredAttribute also has a nice side effect: The relation in the database is created with ON DELETE CASCADE.

I would also recommend making the property virtual to enable Lazy Loading.

2) Create a property called Parent that will serve as a Foreign Key. In that case it probably makes more sense to call it for instance ParentID (you'll need to change the name in the ForeignKeyAttribute as well):

public int ParentID { get; set; }

In my experience in this case though it works better to have it the other way around:

[ForeignKey("Patient")]
public int ParentID { get; set; }

public virtual Patient Patient { get; set; }

What effect(s) can the virtual keyword have in Entity Framework 4.1 POCO Code First

So far, I know of these effects.

Lazy Loading: Any virtual ICollections will be lazy-loaded unless you specifically mark them otherwise.
More efficient change tracking. If you meet all the following requirements then your change tracking can use a more efficient method by hooking your virtual properties. From the link:

To get change tracking proxies, the basic rule is that your class must be public, non-abstract or non-sealed. Your class must also implement public virtual getters/setters for all properties that are persisted. Finally, you must declare collection based relationship navigation properties as ICollection<T> only. They cannot be a concrete implementation or another interface that derives from ICollection<T> (a difference from the Deferred Loading proxy)

Another useful link describing this is MSDN's Requirements for Creating POCO Proxies.

Best Answer

Related Solutions

How Should I Declare Foreign Key Relationships Using Code First Entity Framework (4.1) in MVC3

What effect(s) can the virtual keyword have in Entity Framework 4.1 POCO Code First

Related Topic