Sharing VOs between Webservices

Hello all,

I want to create a set of Webservices that share custom types (User, for example). Just to make it easy to understand, I want to create two webservices:

1.- Users
with method:
Create(string name) --> returns a User

2.- Buy
with method:
Buy(User user, Product product) --> void, for example

The problem is: how do I share User definition between the two webservices? When I add the two web references, two sets of proxies are generated. This two proxies have different namespaces so, actually User in webservice Users is a different class than User from Buy.

How can I avoid this problem without adding a new layer (could be pretty heavy to convert every object to the other using reflection)?

Thank you all

Is there a reason you need two different web services? Can you not just create one service with both methods?

If you do have to use 2, have the "Buy" webservice reference the "Users" webservice. Do not create a user object in the "BUY" service. Use a reference to the user object in the "User" service.

I think it would be best to pass the user id instead of the whole User object into the Buy method. I assume this user id is stored in the database (or somewere else).

Now your buy method is independent of your user object, and you will send less data over the Internet

Hello,

The reason I use two webservices is because each webservice may have around 30 methods, so it's not very reasonable to create a god-service of nearly 300 methods :S

I tried to use references in the webservices in this way:

Program uses Webservices project that uses Model

The class User is in Model. Again, each webservice reference creates a proxy of Model.User inserted in each namespace. So, it doesn't work :(

About passing id instead of the User: just what I want to abstract is the database, so I can pass id instead of the complete User, but I will always receive as result a User class :S

Also, if we are forced to do such tricks, instead of gaining abstraction, we are losing it :S

don't generate your client code. or generate your client code and delete one of the user data structures and modify the second service client proxy to use the single user object. I'm sure it would be possible to code the user schema and reference it from both web services (which may or may not produce a single user data structure from the wsdl generator on the client end), but I've never attempted to do it (as I typically create my client proxies by hand).

I'm a little surprised it is the only solution :S

It can be unmanageable when creating a enterprise application with (imagine) 20 web services with 20 methods each :(

Do you know if is there a webclient generator out of visual studio that addresses this problem?

Thanks all

how is either solution I offered unmanageable? Do you typically write less than 20 class definitions for a solution when you write it by hand? Are you that lazy of a programmer? I shutter to think that that small amount of effort is unmanageable? Have you even investigated referencing a common schema for your data types and writing your WSDL's by hand? I highly doubt that two services which reference the same schema definitions in their WSDL's would generate two different identical data types for their generated client proxies. All of this can be avoided by writing your proxy classes by hand (it's not as bad as you make it out to be, but then again you'll probably have to learn something new rather than letting visual studio generate your code for you in ignorance of what is happening).

perhaps you could use some other language to do the web services, because all of them require orders of a magnitude more coding that C# does.

Yes, you could say I'm pretty lazy when writing anything that doesn't introduce any value to the code. I think that, in the age of dsl, SOA platforms, Bussiness Rules, etc it is difficult to justify to your boss (the guy that tells you that you have one morning to change this three database tables -after all, it doesn't affect anything in your problem-) the introduction of yet another layer of work done by hand. Moreover, when this layer could be easily done by the IDE.

Don't misunderstand me, I'm not criticising your solutions. I'm criticising the fact that it seems there is no automatic solution for a repetitive work that should be easily in an automatic way.

if both sides of the service are owned by you (which I'd doubt) creating a common library which shares the actual data structures used by the web service to generate the schema for the web services can be used by the client proxies.

Other than that I'd highly recommend looking into using a common schema which both wsdl's share (note the link I posted on the xsd/wsdl:import section, and I'm sure Google is full of other .net specific examples). Since all services would effectively be referencing the exact same definitions the generator should not generate identical data types. you may also search for other wsdl generators (because there are a lot more out there) and even look at WCF (which has a far superior client proxy generator) for your client code generation.

Using a proxy definitely adds overhead when you are sharing data contracts between services or have code control over both the web service and clients.

With WCF, you can solve this problem fairly easily. What you do is create a class library that contains your Interface and Contract definitions.

You then include a reference to your class library in your web service project(s).

On the client side, rather than generating a proxy, include the class library and use the ChannelFactory or DuplexChannelFactory class to communicate with the web service (which is what the auto-generated code does under the covers).

If you haven't used WCF before, check it out. It's light years ahead of regular Web Services.

It seems you agree WCF is a good alternative. I'll try it.

Thank you very much :)

Quote:

---

Originally Posted by khainodd

It seems you agree WCF is a good alternative.

---

Yes, I believe WCF is superior. I also agree that the WCF client proxy generator is superior as well, but with the approach I've outlined, I'm suggesting not to use it (otherwise you end up with the same duplicate classes with different namespace issues).