views:

1800

answers:

3

Hi guys, as you can probably tell from my rep, I have just got my invite so I am a complete n00b! :D First off I would like to say thanks to Jeff and the team for what looks like is going to be an excellent site for the community.

So, my question:

I am still kinda new to the ASP.NET world, so I could be way off base here, but so far this is to the best of my (limited) knowledge!

Lets say I have a standard business object.. "Contact" in the Business namespace.. I write a Web Service to retrieve a Contact's info from a database, and return it. I then write a client application to request said details.

Now, I also then create a utility method that takes a "Contact" and does some magic with it, like Utils.BuyContactNewHat() say.. Which of course takes the Contact of type Business.Contact.

I then go back to my client application and want to utilise the BuyContactNewHat method, so I add a reference to my Utils namespace and there it is. However, a problem arises with:

Contact c = MyWebService.GetContact("Rob);
Utils.BuyContactNewHat(c); // << Error Here

Since the return type of GetContact is of MyWebService.Contact and not Business.Contact as expected.
I understand why this is, because when accessing a web service, you are actually programming against the proxy class generated by the WSDL..

So, is there an "easier" way to deal with this type mismatch? I was considering perhaps trying to create a generic converter class that uses reflection to ensure two objects have the same structure, then simply transferring the values across from one to the other..

Thanks guys, sorry for the long question, just wanted to ensure I explained the problem clearly :)


EDIT: Thanks to Lance Fisher for the answer posted. If anyone can recommend and good methods for the "deep copy" of the objects in question, I would love some input! :)


EDIT: Thanks to Dan Thompson for the idea on copying the code generated by VS via WSDL. I have looked at that sort of scenario before, but the problem is that the services are succeptable to change, meaning the "hack" requires regen, re-copy, re-edit etc. I have +1'd this though since it is a good idea, especially for services that are pretty mature and not likely to change. Thanks.

+2  A: 

You are on the right track. To get the data from the proxy object back into one of your own objects, you have to do left-hand-right-hand code. i.e. copy property values. I'll bet you that there is already a generic method out there that uses reflection.

Some people will use something other than a web service (.net remoting) if they just want to get a business object across the wire. Or they'll use binary serialization. I'm guessing you are using the web service for a reason, so you'll have to do property copying.

Lance Fisher
+2  A: 

You don't actually have to use the generated class that the WSDL gives you. If you take a look at the code that it generates, it's just making calls into some .NET framework classes to submit SOAP requests. In the past I have copied that code into a normal .cs file and edited it. Although I haven't tried this specifically, I see no reason why you couldn't drop the proxy class definition and use the original class to receive the results of the SOAP call. It must already be doing reflection under the hood, it seems a shame to do it twice.

d4nt
A: 

I would recommend that you look at writing a Schema Importer Extension, which you can use to control proxy code generation. This approach can be used to (gracefully) resolve your problem without kludges (such as copying around objects from one namespace to another, or modifying the proxy generated reference.cs class only to have it replaced the next time you update the web reference).

Here's a (very) good tutorial on the subject:

http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx

Mark