Shared type library for .net webservice and client ... how?

[TheRift]

Does that title mean anything to anyone? I'm frustrated with this .net thing now.

I'm using .net 2.0 for web service and web application.

I have a class library which contains class for my common data structures (not structs, but classes).
Something like:

namespace moocow {
  public class moocowData_A
 {
     public string Value { get; set; }
  }

  public class moocowData_B
  {
     public string Value { get; set; }
  }
}

I include this class library in both the web app and the web service where they use it for whatever they need.

Now in the webservice I have a method like this:

  [WebMethod]
  public moocowData_B ProcessCowFromAtoB(moocowData_A some_adata)
  {
      moocowData_B some_bdata = ShakeItUp(some_adata);
      return some_bdata;
  }

Add reference to the web service in the web application and it generates the service proxies with new classes for the data objects which obviously conflicts with the classes in my common class library.

On the client web application I am just trying to do the following:

  thatMoocowService tms = new thatMoo...

  moocow.moocowData_A = new moocow.moocowData_A();
 // set some values in it and then send to web service which has the same class library dll reference

  moocow.moocowData_B = tms.ProcessCowFromAtoB(mcd_a);

I'm basically trying to share a common type library between web service and its client/consumer, but ofcourse this idea goes against the whole idea of SOAP, etc, etc.

Is there some elegant way to handle this?

I've found some options. The first involves manually altering the reference.cs file for the webservice reference in the web application and switching out all references to the client proxy types with the matching data classes in the class library, but this will fail whenever the web reference is updated.

The other option is to switch the .net 2.0 web service to a WCF service and use DataContract, etc, but unfortunately I don't have the liberty of using 3.0/3.5.

If anyone has a good/clean/elegant solution to sharing a common data class/type library between a webservice and the client then please let me know how you did it.

It seems to be a fairly common annoyance, but not many solutions out there.

 

[crazy_cat]

can you explain further

Add reference to the web service in the web application and it generates the service proxies with new classes for the data objects which obviously conflicts with the classes in my common class library.

 

[crazy_cat]

i suggest making the types you use in webservice calls generic. any logic should move a service class as dequadin mentioned..

 

[TheRift]

I am doing it this way because the common classes/types are used everywhere and for ease of use. To keep the class types consistent between web service and client I use the separate class library (a project on its own). This would (clearly in theory) allow both service and client to handle the same types and make thinking about it in the proper types alot simpler.

To describe it a bit more; the client first fills up a collection of the type A with information and needs to get a resulting type B collection by sending type A collection to the webservice and returns the correct type B collection without the client having to go through the returned result and create a type B collection. I mean, it's been done already and it should just deserialize to a type B collection.

Since I have included the class library in the web service and created the webmethod to use the defined class names it produces a client proxy with the names of those classes. Back in the client one winds up with two classes with the same name (one defined in the class library, the other in the client proxy for the service). Since they're identical it would reason that they could be replaced by the same class from the class library.

 

[TheRift]

i suggest making the types you use in webservice calls generic. any logic should move a service class as dequadin mentioned..

How would you make them generic?

The logic/functionality around the data types isn't the issue. Looking for a way to deserialize the incoming webservice response to the same data types used on the webservice.

 

[TheRift]

can you explain further

Add a web reference to a project and have a look in the resulting reference.cs file and you'll see the classes defining the complex returned types.

 

[guest2013-1]

First off, separate whatever you're doing from the web-service and web application. You do not need to have the class on both ends only the type.

Not entirely 100% sure but you might need to re-evaluate why you're using a web-service in the first place if you already have a web application going (unless it's for some kind of API, whereas I'd suggest stick everything in the web-service and just call from the web application what you need)

 

[FarligOpptreden]

A possible solution might be to accept the incoming type via SOAP, but use the serialized XML. Transform the serialized XML to the local type, defined in the class library, via an XSLT stylesheet and then deserialize the resulting XML to the type defined in your class library and use them as you normally would. The same can apply the other way around as well. I've done something similar, but not exactly the same as your scenarion, and this solution worked perfectly.

 

[TheRift]

Yes, ofcourse it is defined in the WSDL, but I'm not adding it twice. Because the classes are named the same on webservice and client the definition winds up having the same name and so on.

I'm just shifting out a small piece of functionality to a web service.

Sorry, I know it's a little difficult to explain on short messages.

Just did the manual thing now and gave it a go and it works fine. Class on service and client in the same library, therefore identical therefore serialize to/from the same thing. I removed the class definitions from the reference.cs, add reference to my class library namespace and it will pick them up from there. Working sweet it seems.

 

[TheRift]

I think this is similar to DataContracts in WCF in 3.0/3.5. Not sure. From what I've read if I go that route it'd be simple, but alas I cannot.

 

[crazy_cat]

i personally think that because your client and server are using the same data types, there is a flaw in the design of your architecture, so i ask why do the client and server need the same types as opposed to pushing simple data (required for type A) and let the webservice convert to the required types (typeB) for processing?

[WebMethod]
public moocowData_B ProcessCowFromAtoB(moocowData_A some_adata)
{
moocowData_B some_bdata = ShakeItUp(some_adata);
return some_bdata;
}

i like asking questions, so herewith is another one.... why does this need to be in a webservice? to me " ShakeItUp(some_adata)" is some business logic that needs to be in the moocowData_B class or the corresponding service/business logic class (assuming your domain model is not anaemic in design)

I'm just shifting out a small piece of functionality to a web service.

hmmm.. this further re-iterates my first point and leads me to believe that your design is tightly coupled.

 

[TheRift]

i personally think that because your client and server are using the same data types, there is a flaw in the design of your architecture, so i ask why do the client and server need the same types as opposed to pushing simple data (required for type A) and let the webservice convert to the required types (typeB) for processing?

No flaw. It's the same data type. I see no point in having another conversion routine for the same data type. It's a common data type.

It can't be such a horrible thing if they have the facility in WCF.

i like asking questions, so herewith is another one.... why does this need to be in a webservice? to me " ShakeItUp(some_adata)" is some business logic that needs to be in the moocowData_B class or the corresponding service/business logic class (assuming your domain model is not anaemic in design)

No business logic or such in it, it's a data interface hiding different data base systems in the background. Yes, could handle it with a DLL taking care of the differences, but redeployment is easier on a single webservice when a new type of DB is added rather than updating a DLL and having to deploy those to 4-5 locations. Apart from that they want it for things like php, etc.

hmmm.. this further re-iterates my first point and leads me to believe that your design is tightly coupled.

In certain places yes, but not everything everywhere needs to loosely coupled. It is if it has to be.

 

[TheRift]

i like asking questions, so herewith is another one.... why does this need to be in a webservice? to me " ShakeItUp(some_adata)" is some business logic that needs to be in the moocowData_B class or the corresponding service/business logic class (assuming your domain model is not anaemic in design)

By the way ... if you saw this thing you'd be as tempted as I am to press delete and run as well.

 

[crazy_cat]

a bit off topic, but....

if you can would you describe what the system does, and how it works and operates? relationship between client, server, db(s) etc. and the type of design patterns you used. I am very much interested in this as this intrigues me.

also, what technologies are you using?