how to use your same Domain entities throug a .Net webservice?

Question

if you have an entity which is reference in the client and a webservice like this

public class Post
{    
        public int ID {get; set;}
        string Data {get; set;}
}



 public class MyService: System.Web.Services.WebService
 {   
         [WebMethod]
         public int Write (Post post)
         { 
               //Do stuff

         }
 }

on the client in order to use the entity you to instantiate from the proxy class

   public void ClientMethod()
      {
         var post = new proxyclass.Post();
         //fill post
         new ProxyClass.Myservice().Write(post) 

       }

how can i use my domain entity to call the webservice?

 public void ClientMethod()
          {
             var post = new Post();
             //fill post
             new ProxyClass.Myservice().Write(post) 

           }

Answer 1

Basically, you can't - with regular web-services, at least... the proxy class is completely separate. However, the above is possible with WCF, where you don't actually need proxy classes at all (however, for SOA purity it is a good idea to use them).

You could use reflection (etc) to copy the properties between your domain entities and the proxies, but it is quite hard to get this 100% right (although xml serialization should work [in theory] as an intermediate language).

---

So; if you want to use assembly sharing; consider using WCF, which supports this ;-p

To get hold of a service without using a proxy layer, you can do tricks like:

public class WcfClient<T> : ClientBase<T> where T : class
{
    public T Service { get { return base.Channel; } }
}

(this will access the default configuration from the app.config; for more control you need to add a few constructor overloads matching to the base constructor overloads)

Then:

interface IFoo {void Bar();}
...
using(WcfClient<IFoo> client = new WcfClient<IFoo>()) {
    client.Service.Bar();
}

Answer 2

Take a look at this article: http://www.codeproject.com/KB/WCF/WCFCollectionTypeSharing.aspx (Sharing WCF Collection Types between Service and Client)

Answer 3

I suspect that one of these might answer your qestion. The common theme is wsdl.exe /sharetypes and svcutil /reference.

http://stackoverflow.com/questions/578955/managing-2-web-references-with-shared-class-dependency-in-a-net-project http://stackoverflow.com/questions/216884/force-net-webservice-to-use-local-object-class-not-proxy-class http://stackoverflow.com/questions/209224/-net-consuming-web-service-identical-types-in-two-different-services http://stackoverflow.com/questions/224474/how-to-get-a-webserice-to-serialize-deserialize-the-same-type-in-net http://stackoverflow.com/questions/127395/-net-soap-common-types http://stackoverflow.com/questions/489542/wsdl-exe-sharetypes

Answer 4

You should use WCF for new development whenever possible.

However, you should reconsider your reasons for wanting to use your domain class on the client. It does violate the principles of SOA by exposing to the client some details of the implementation of the service. Why should the client know anything about your entity classes, beyond the data that they contain?

For instance, your entity classes may contain methods to save the entity to the database. Why does your client need access to that method?

Also, one of the principals of SOA is to interoperate with different platforms. As soon as you require your client to use your (.NET) entity, you prevent a Java or PHP client from being written to use your service.

You may have good enough reasons to overcome such objections, but I recommend that you think it through and make sure your reasons are good enough.