Correct pattern of methods invocation on WSDL-generated type

[alexttp]

Introduction:
Assume having a MyApp.MyClass class bearing both data (say, DataSets)
and functionality (proprietary methods).
A WebService exposes this class via some GetMyClass WebMethod.
A WSDL-generated proxy class (localhost.MyClass) on the client side,
naturally, has only the data of the original class "mirrored" (well,
that's reasonable, since the WebServices are there to provide data
objects...).

Now, to the question.
What is the proper pattern to be applied in order for the client to be
able, after receiving a (proxy-side type, localhost.MyClass) object
from GetMyClass WebMethod, to be able to invoke the methods of the
original MyApp.MyClass on that object's data?

Is it something to do with namespaces?
Should I build a library to be put on the client side (in the GAC?)
and referenced from the client object?
Should I create & override (extend) the proxy class by myself, and
provide the client with it (instead of client's generating the proxy
by itself)?

Please advise...

[Dino Chiesa [Microsoft]]

yes, as you point out, the philosophy of webservices is to exchange
MESSAGES, not objects.

Therefore I advise you to use the DTO pattern.
http://msdn.microsoft.com/library/en...tml/DesDTO.asp

If you want to violate the philosophy of sending messages, and actually send
objects across the wire, then , yes you can do that too.

follow these steps:
define your service class to return MyClass
Build your shared MyClass into a distinct (shared) assembly
install that assembly on both client and server
generate the webservice proxy in the normal way
modify the webservice proxy - remove the generated (neutered) type and
replace it with the SharedAssembly.MyClass
off you go.

-Dino

"alexttp" <al*****@yahoo.com> wrote in message
news:85**************************@posting.google.c om...

Introduction:
Assume having a MyApp.MyClass class bearing both data (say, DataSets)
and functionality (proprietary methods).
A WebService exposes this class via some GetMyClass WebMethod.
A WSDL-generated proxy class (localhost.MyClass) on the client side,
naturally, has only the data of the original class "mirrored" (well,
that's reasonable, since the WebServices are there to provide data
objects...).

Now, to the question.
What is the proper pattern to be applied in order for the client to be
able, after receiving a (proxy-side type, localhost.MyClass) object
from GetMyClass WebMethod, to be able to invoke the methods of the
original MyApp.MyClass on that object's data?

Is it something to do with namespaces?
Should I build a library to be put on the client side (in the GAC?)
and referenced from the client object?
Should I create & override (extend) the proxy class by myself, and
provide the client with it (instead of client's generating the proxy
by itself)?

Please advise...