WCF, Entity Framework 4.1 and Entity's State
U

2

0

I am developing an application which will expose WCF services. I am using Entity Framework 4.1 at the DAL. The problem is when I load some entity (let say a Customer that has Order which in turn has OrderDetail). After loading it I make some changes in Customer, Order and OrderDetail objects (some new orders are added and some existing orders are removed/updated) and send the object graph to WCF service to update it as following.

Customer oCustomer;
using(var context = new MyContext) //MyContext is dbContext
{
    oCustomer = context.Include("Order.OrderDetail").Find(1);
}

oCustomer.Name ="blah blah";
Order oOrder1 = oCustomer.Order.Where(obj=>obj.Id == 2);
oOrder1.Description = "blah blah";
oOrder1.OrderDetail.Quantity = 10;

Order oOrder2 = new Order { ... } //properties of Order are set.
oCustomer.Order.Add(oOrder2);

oCustomer.Order.Remove(context.Order.Find(1));

ServiceClient client = new ServiceClient();
client.SaveCustomer(oCustomer);

Now when I receive the updated ObjectGraph of Customer at Server side I don't know which Order was removed and which was modified, since there is no changetracking now. How can I determine that which Order to Delete and Which Order to Modify? Is there any way to track the changes in my object graph in Entity Framework 4.1?

NOTE: Previously I used Self Tracking Entities which solved this problem but I had to get rid of STEs since my WCF service is gonna be used by Java Client apps as well. So, STEs are not an option for me.

Untutored answered 10/8, 2011 at 16:28 Comment(0)
S
2

As far as know there is no way to track changes of a detached object graph aside from Self Tracking Entities (which you can't use as you say).

What I usually do to update a detached graph is to reload the original graph from the database, compare the original with the changed graph (hand-written code case by case) to see which entities have been added, modified and deleted, write the changes into the original and save the context.

An example to this procedure (for one parent and a child collection, for instance Customer and Order collection) is in the answers to this question: The relationship could not be changed because one or more of the foreign-key properties is non-nullable

It's unfortunately getting quite complex if you have to deal with a deeper hierarchy of entities. As far as I can see EF doesn't offer any kind of automatic merging of a changed graph into the original, only for the very simple case where an entity only has scalar and complex properties which have been changed. As soon as navigation properties are involved you have no support from EF anymore and you have to write the update logic yourself.

Sequestration answered 10/8, 2011 at 17:47 Comment(0)
P
3

I wonder if it makes any sense to answer your questions because it looks like you don't read answers.

You asked question about STEs and you got answers about their usability.

  • I added link where it was explicitly described that they are not for interoperable scenarios
  • Richard posted very good links about STEs and about custom change tracking - btw. it is exactly what you are looking for now

You probably didn't read those answers because you used STEs and after that you asked a question how to use STEs in Java client.

What surprise me even more you did duplicate of your own question about STE and EFv4.1

Today you already get an answer for this question in another your question.

So what answer do you expect? Does it worth it to answer your questions if you don't read answers?

Answer:

There isn't STE template for DbContext and once you are not using STEs you must handle change tracking completely yourselves because EF doesn't help you. The easiest approach is described in your previous question - load the object graph again in the service and merge incoming graph to attached entities so that context can track changes. The more complex solution is described in the link @Richard provided in one of your former questions about STE - you must add some state property to each transferred entity and client must set them correctly and post them back to you so that you can manually set correct state for each entity once you attach them - this can be little bit complex in case some relations.

Pulpboard answered 10/8, 2011 at 17:48 Comment(1)
Thanks for the guidance. But, I have been reading all the answers. I agree that couple of my questions were a duplicate in some sense. I had to do that in quest of a better and elegant solution.Untutored
S
2

As far as know there is no way to track changes of a detached object graph aside from Self Tracking Entities (which you can't use as you say).

What I usually do to update a detached graph is to reload the original graph from the database, compare the original with the changed graph (hand-written code case by case) to see which entities have been added, modified and deleted, write the changes into the original and save the context.

An example to this procedure (for one parent and a child collection, for instance Customer and Order collection) is in the answers to this question: The relationship could not be changed because one or more of the foreign-key properties is non-nullable

It's unfortunately getting quite complex if you have to deal with a deeper hierarchy of entities. As far as I can see EF doesn't offer any kind of automatic merging of a changed graph into the original, only for the very simple case where an entity only has scalar and complex properties which have been changed. As soon as navigation properties are involved you have no support from EF anymore and you have to write the update logic yourself.

Sequestration answered 10/8, 2011 at 17:47 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.