Wiring up returned object instances in a WCF client

I have a WCF service that can return several different collections.

Objects in each collection can have references to objects in the other collections. Eg. I have a collection of orders, an开发者_如何学运维d a collection of customers. Customer objects contain a collection of order references, and each order contains a customer reference.

I was wondering how people generally handle this kind of thing on the client side. As far as I can see, my choices are:

1) Just let WCF serialise any member objects in full, and don't worry about duplication. I know I can use [PreserveReferences] to mitigate this to some extent, but there is still an awful lot of duplication and unnecessary serialisation going on. Ie, if I request a customer object from the service, it will serialise all members of every order that the customer has, even though I already have those objects on the client side in my orders collection. This also means I must be careful to match things by Id all the time rather than just comparing instances.

2) Serialise Id's rather than instances. This seems like the most sensible approach, but means I have to have some point where I turn these Id's into instances again on the client side. This brings a whole mess of where to do this, and how to inject the required repositories to do the wiring up.

3) Just use Id's everywhere in the client instead of wiring up instances. This just feels wrong to me, and moving away from the whole point of OOP. Instead of accessing a collection on the object, I have to access a collection of id's and then look them up via some global repository.

At the moment I'm leaning towards 2, but am not liking the serialisation mess this is going to be.

I should note that the client is probably a lot more stateful than most WCF clients, and it maintains an open connection to the service with callbacks etc to maintain its collections, since it is displaying realtime data.

Cheers

I think another option is not to retrieve the collection of data by default. Using your example, I could define several WCF methods:

ListCustomers() -- Return customer objects but do not fill the Orders Collection ListOrders() -- Return order objects, each of them attached with a customer object, but the customer object does not have order information.

ListOrdersForCustomer(id customer) -- Return the orders for a specific customer.

Of course, this has its own drawbacks, but might work for your example.

Having 12 months of experience under my belt I thought I would update this with my solution.

I now use separate DTO objects for serialisation over WCF. Some of these use id's, some contain full object graphs. The beauty of using DTO's mean I can return different formats of the same business object depending on the caller's needs.

At the client end I effectively have two layers. DTO's can be used directly straight from the service (by requesting full object graphs containing only what I need), but I also maintain a set of repositories of business objects at the client end. These repos update themselves using DTO's with just id's, and the wiring up of references is done at the point the DTO is translated into a business object. As I said in my OP, my client is a lot more stateful than most WCF clients, and the repos also listen for service callbacks with updated objects.

The result is that client code can use the client repos as if they were running at the service end, and object references can be wired up without duplicating info across the wire.