EF4 Self Tracking Entities

I am currently trying to use STE's in an n-tier scenario. I have a WCF service that allows me to retrieve a graph of objects and/or update objects along with a client (WPF) application that allows me to edit aspects of that graph and submit the changes back to the service.

My problem is this; the graph of objects that I retrieve is quite large - sometimes including images - but my updates are minimal. However, when I submit an update, the entire graph is submitted back to the service due to the relationships between the objects.

For example; given a Customer/Order/OrderDetail scenario: I retrieve a Customer with their Orde开发者_如何学JAVArs and the related OrderDetails (3 levels). I then update a single OrderDetail to perhaps change the quantity. I submit the OrderDetail to be updated via a WCF method that takes an OrderDetail object but the serialization follows the relationship properties through the Order to the Customer and serializes not only the changed OrderDetail but all Orders, OrderDetails and the customer.

How can I stop all of this from being passed back when the service call parameter is serialized and just pass back the object to be updated without following the relationships?

All of the examples that I can find for STE's (and there are still not many) seem to be designed to actually pass all related objects (such as the blog/postings example online).

As you know the ObjectStateManager manages the objects statuses, especially on n-tied applications, to update specific objects, use below methods:

1. attach it to context first
2. ChangeObjectState - accepts an enum of EntityState: Added/Modified/Deleted
3. SaveChanges

check link: http://msdn.microsoft.com/en-us/magazine/ee321569.aspx

If you don't want all data to be passed you must work with smaller set. So if you by default retrieve Customer + all its order + all order details then it is your working set. If you want to work only with single Order create operation to get only that one and its details.

It is somehow related to aggregate roots. Order is aggregate root for order items because working with single item without its order doesn't make too much sense. But working with Order without its customer is probably possible, isn't it?