Posting returned instances of objects in the WCF client

Question

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

Objects in each collection may have links to objects in other collections. For instance. I have a collection of orders and a collection of customers. Customer objects contain a set of links to an order, and each order contains a customer link.

I was wondering how people usually deal with such things on the client side. As far as I can tell, my options are:

1) Just let WCF serialize any member objects in full and not worry about duplication. I know that I can use [PreserveReferences] to mitigate this to some extent, but there is still a lot of duplication and unnecessary serialization. That is, if I request a client object from a service, it will serialize all the members of each order that the client has, even if I already have these objects on the client side in my order collection. It also means that I have to be careful to match things by id all the time, and not just compare instances.

2) Serialization identifier, not instances. This seems like the most sensible approach, but means that I should have some time when I return that identifier to instances on the client side again. This leads to confusion about where to do this and how to enter the necessary repositories for posting.

3) Just use Id everywhere in the client, and not connect instances. This is simply wrong for me and moves away from the whole OOP point. Instead of accessing the collection on the object, I have to access the collection of identifier and then view them through some global repository.

Right now I'm leaning towards 2, but I don't like serialization.

I should note that the client is probably much more resilient to the state than most WCF clients, and supports an open connection to the service with callbacks, etc. to support his collections as he displays real-time data.

Greetings

Answer 1

Having 12 months of experience under my belt, I thought I was updating this with my solution.

Now I use separate DTO objects for serialization by WCF. Some of them use id, some contain full graphs of objects. The beauty of using DTO means that I can return different formats of the same business object depending on the needs of the caller.

On the client side, I actually have two layers. DTO can be used directly from the service (by requesting complete graphs of objects containing only what I need), but I also support a set of client object repositories of business objects. These repositories update themselves using DTOs with identifiers only, and the link is posted at the point where the DTO is converted to a business object. As I said in my OP, my client is much more resilient than most WCF clients, and repositories also listen for service callbacks with updated objects.

As a result, client code can use client repositories, as if they were executed at the end of the service, and links to objects can be connected without duplicating information on the wire.

Answer 2

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

ListCustomers () - Returns client objects, but does not fill out the collection of orders. ListOrders () - return order objects, each of which is associated with a client object, but the client object does not have order information.

ListOrdersForCustomer (client id) - returns orders for a specific client.

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