Has anybody figured out a good way to persist objects (via Serialization or over Web Services) that is contained in objects?

Basically my usage scenario is that I have business objects that contain DataSets (and DataRows which fails outright right now) to represent their internal object state. This works real well from an operational point of view, but in terms of distributed systems this approach totally falls flat due DotNet's apparent inability to persist DataSets into the XML of an exported object graph.

So, now I'm looking at how to get my business object data returned to a client side application without piecing everything together manually...

I can think of several ways to do this, none of them pleasing. THe first would be to just bite the bullet and build a custom dataset with the data compiled from the various datasets that make up the data of the various bus objects. This could potentially be a number of datasets dumped together because the business objects may be hierarchical. This would obviously be a mess and totally ignore all the work the business objects already are doing to create the data in the first place.

The other option is to have more granular methods on the Web Service that allows returning all the pieces one at a time, and then reading that data into a client side version of the object. In some ways this would work fairly well because Web Service Proxies are not very useful 'live' objects - they're just decent data containers in the first place. If instead I push and pull just the data I need for the bus object I'm actually taking some part of the owrk I'd have to do anyway. Better but still not great...

Finally I suppose it'd be possible to build a custom serializer that can deal with DataSets - since DataSets at least can be persisted into XML. But there are other issues such as DataRows which can't be which is a bit of a drag too.



Anybody have any more ideas (maybe the obvious I'm missing?)

+++ Rick ---