Large, Complex Objects as a Web Service Result [closed]

Question

Hello again ladies and gents!

OK, following on from my other question on ASP.NET Web Service Results, Proxy Classes and Type Conversion. I've come to a part in my project where I need to get my thinking cap on.

Basically, we have a large, complex custom object that needs to be returned from a Web Service and consumed in the client application.

Now, based on the previous discussion, we know this is going to then take the form of the proxy class(es) as the return type. To overcome this, we need to basically copy the properties from one to the other.

In this case, that is something that I would really, really, really! like to avoid!

So, it got me thinking, how else could we do this?

My current thoughts are to enable the object for complete serialization to XML and then return the XML as a string from the Web Service. We then de-serialize at the client. This will mean a fair bit of attribute decorating, but at least the code at both endpoints will be light, namely by just using the .NET XML Serializer.

What are your thoughts on this?

Answer 1

The .Net XML (de)serialisation is pretty nicely implemented. At first thought, I don't think this is a bad idea at all.

If the two applications import the same C# class(es) definition(s), then this is a relatively nice way of getting copy-constructor behaviour for free. If the class structure changes, then everything will work when both sides get the new class definition, without needing to make any additional changes on the web-service consumption/construction side.

There's a slight overhead in marshalling and demarshalling the XML, but that is probably dwarved by the overhead of the remote web service call. .Net XML serialisation is well understood by most programmers and should produce an easy to maintain solution.

Answer 2

I'm loving JSON for this kind of thing. I just finished a POC drop-things type portal for my company using jQuery to contact web services with script service enabled. The messages are lightweight and parsing etc is pretty much handled. The jQuery ajax stuff I read was here (loving it!) : jquery ajax article

Answer 3

I had some great answers on a very similar topic yesterday that might be useful for you:

Communication between javascript and the server

Answer 4

Rob, in looking at your other question as well as this one, it's sounds like the exact situation we have in our environment. What we've done, however, is move away from ASP.Net web services to WCF web services and in the process solved (for the most part) this problem.

If there is any chance your web service could be implemented as a WCF web service, this might work for you as well. I should mention, that at the same time, we've maintained backwards compatibility with some client applications that need the "ASP.Net web service style" of implementation by using the WCF basichttp binding for the service transport. The end result is that our "newer" client applications are able to use our real business objects (through referencing an assembly containing only these shared objects) as the return types from the web service calls because they make actual WCF calls.

We do this by not utilizing the auto-generated proxy classes and constructing our own client channel to communicate with the WCF service.

If you can possibly use WCF, let me know I can post some additional information.