S
Sarge
Hi all,
tough question. Apologies for the cross posting but it is an interesting
architectural problem and I think deserves a wide audience.
What is the best way to extend web service proxy classes so we can add
our own methods and properties?
We have an application that passes a deep hierarchical structure (four
nodes deep) between a webservice and a smart client.
We have built the web service using the Contract First Web Service Tool,
which essentially builds nice web service proxy classes from a WSDL and xml
schemas, nothing new here. This tool uses the xsd.exe generation tool + IDE
integration, rather nice.
On the client side of the application we need to do some complex / semi
real time processing on this hierarchy before sending it back.
We would like to extend the web service proxy classes without modifying
the generated class files directly as we know that these things tend to
change and code generation is a big help in this manner.
We need properties and methods to be added to the individual web service
proxy classes
Attempts
We have tried inheriting from the web service proxy class.
This didn't work so well for two reasons
a) we can't down cast from a super class into sub class. i.e can't
cast from a type Dog into type Dalmatian
b) we have a hierarchy of classes so even if we can get a successful
cast into a Dalmatian class if we have a collection of FriendsToSniff they
would need to be cast as well...
Another option is to recreate the whole hierarchy, this seems to be an
expensive option after all the xmldeserializer has just kinda done all this
creating.
Another other option is use some kind of helper class which we could use to
help with the processing, this would be possible but complicated and would
not support the addition of properties easily as new properties would need
to be implemented as hashtables inside the helper class or something like
that. Helper classes are good for processing but not properties and state.
So you code hounds and architectural sleuths what do you think??
Thanks in advance
Mark
tough question. Apologies for the cross posting but it is an interesting
architectural problem and I think deserves a wide audience.
What is the best way to extend web service proxy classes so we can add
our own methods and properties?
We have an application that passes a deep hierarchical structure (four
nodes deep) between a webservice and a smart client.
We have built the web service using the Contract First Web Service Tool,
which essentially builds nice web service proxy classes from a WSDL and xml
schemas, nothing new here. This tool uses the xsd.exe generation tool + IDE
integration, rather nice.
On the client side of the application we need to do some complex / semi
real time processing on this hierarchy before sending it back.
We would like to extend the web service proxy classes without modifying
the generated class files directly as we know that these things tend to
change and code generation is a big help in this manner.
We need properties and methods to be added to the individual web service
proxy classes
Attempts
We have tried inheriting from the web service proxy class.
This didn't work so well for two reasons
a) we can't down cast from a super class into sub class. i.e can't
cast from a type Dog into type Dalmatian
b) we have a hierarchy of classes so even if we can get a successful
cast into a Dalmatian class if we have a collection of FriendsToSniff they
would need to be cast as well...
Another option is to recreate the whole hierarchy, this seems to be an
expensive option after all the xmldeserializer has just kinda done all this
creating.
Another other option is use some kind of helper class which we could use to
help with the processing, this would be possible but complicated and would
not support the addition of properties easily as new properties would need
to be implemented as hashtables inside the helper class or something like
that. Helper classes are good for processing but not properties and state.
So you code hounds and architectural sleuths what do you think??
Thanks in advance
Mark