Hi,

I was wondering if there is any chance additional support will be added to support IXmlSerializable in prefetch paths and filters and some of the other parameters to FillCollection. I would like to specify these things on the client side, and have them serialize to the web service.

At the moment it seems that the serialisation support is only supported for EntityCollection for web services and not the other classes.

Regards Craig.

Good point. However it's a bit cumbersome to implement IXmlSerializable on all those objects, as it's not an easy task, and most webservices expose an API which returns objects while accepting values or receiving objects (for save).

Hi,

Yes, I suppose that is the case. Why is implementing IXmlSerializable so cumbersome, can one not just use the XmlSerializer to serialise POCO Serializable objects, which then gives you IXmlSerializable almost for free?

Regards Craig

craigmain wrote:

Hi,

Yes, I suppose that is the case. Why is implementing IXmlSerializable so cumbersome, can one not just use the XmlSerializer to serialise POCO Serializable objects, which then gives you IXmlSerializable almost for free? Regards Craig

Heh, if it was that easy, I'd do it immediately

The main problem is that at the receiving side, so the webservice describing side, WSDL.exe creates classes for every type it sees on a webservice interface which isn't a known type. So if you have this method:

[WebMethod] public EntityCollection GetCustomers(PredicateExpression exp) { //... }

wsdl.exe will generate a class called 'PredicateExpression' at the client. You don't want that of course, you want to use the PredicateExpression class in the ORM support classes.

Another problem is that the XmlSerializer can't deal with interface based types. That's pretty much a showstopper in this case, as internally the runtime code uses a lot of interfaces, to keep the code generic. The XmlSerializer throws an exception when it encounters an interface and you can only intercept that by implementing IXmlSerializable. When you do that, you have to write and read teh XML yourself. So I have to serialize a complete predicateexpression graph to Xml and back. or a prefetch path graph.

It will solve the regeneration of classes thing, but at the same time wsdl will think that in that case PredicateExpression is a dataset.

All in all: webservices are nice for some situations, but IF you can, use remoting, because in there this misery isn't there, it just works.

Taken into account all the time I lost for this webservice crap, I can only conclude that I'm very bitter about 'webservices' in general and how MS pushes it in particular. The tools they provide aren't up to par (with .NET 2.0 it's a bit better), and push you into a corner which is only suitable for their own 'dataset' pattern. How convenient.

In my opinion the predicates etc don't need to be serializable. You can pass the parameters for a search in an array then create your predicates from the array.

Like Frans said webservices are very good for certain situations. If your building a compact framework app for instance, remoting is not available. Personally myself i really like webservices becuase they are simple and easy. But as Frans pointed out the tools suck for using anything but simple objects which is a shame. At least witht he new version the entities and entitecollections can be passed, so i am happy