What is the best approach to deal with object graphs across tiers/layers?

We have a typical multi-tier/layer architecture. Application + WCF Service + Repository/EF4/Database.

We are using a customized version of the EF POCO T4 template to generate our entities, that we use across the tiers/layers. We have decided not to use DTO, because of the additional time/work involved.

An example object would be a forest which could have navigation properties of trees which could have navigation properties of leaves.

What is the best approach to add leaves and deal with the object graph? The data is being imported from the client side, so we don't necessarily know if the parent forest/tree already exists in the database.

1. Query service and retrieve any existing related objects. Attach graph for related objects or create new objects and attach graph on the client side. example: public Forest GetForest(string forestid) then --- public void AddLeaf(Leaf leaf)

2. Create the forest, tree, and leaf objects on the client side and attach the graphs. Send the leaf object across and then on the server side perform logic to compare objects to existing objects in the database. Strip graphs if required, add items that do not exist and/or attach to existing objects. e开发者_JAVA技巧xample: public void AddLeaf(Leaf leaf)

3. Create the forest, tree and leaf objects on the client side, but don't attach the graphs. Send the objects across and then on the service side perform the logic to compare objects to existing objects in the database. Add items that do not exist and/or attach to existing objects. example: public void AddLeaf(Leaf leaf, Tree tree, Forest forest)

The question boils down to where should the logic take place to attach the graphs of these related objects. On a side note I am a little concerned about the "fixup" logic for the navigation properties when dealing with graphs being serialized and deserialized. It seems like that could become an expensive opearation.

Note: The client application is a windows service that is importing data...so it is not necessarily a light weight client. (We are not necessarily afraid of adding logic to it.)

---

I had similar question few months ago. After playing a lot with this problem my final decission is to use your third solution (my client is always web application). This solution requires writting a lot of code and it includes some additional database queries because each time you want to update your objects you have to load whole object graph first. Reason for this is that when working with detached objects you have to deal with change tracking manually.

When you use third solution you can also involve DTO and transfers only really needed data between client and server.

In case of statefull client (windows app written in .NET or maybe Silverlight) you can also use self tracking entities and your first approach. Self tracking entities are implementation of Changeset pattern. They can track all changes after detaching from context but you have to load your entities first from DB. Self tracking entities are not a good choice in case of web application client or service consumed by non .NET client.