Question

What is a good way to create a WCF service layer so that a native .Net client application and other client types can talk to the service?

I know, in the future our applicaiton will need to support mobile devices.

We are passing objects into our WCF methods similar to this:

    [DataContract]
    public class User: DomainBase
        {
            [DataMember]        
            public string Username { get; set; }
            [DataMember]
            public string Password { get; set; }
            [DataMember]
            public string FirstName { get; set; }
            [DataMember]
            public string LastName { get; set; }
}  

So there may be a method in our servcie like this:

public bool Save(User item){
   ...do some work
}   

public User GetUserByUsernameAndPassword(string username, string password){
   ...do some work
}    

Now, in .Net I can use the same object library as my services, but with other clients I will not be able to. So, if I don’t want to write a bunch of differnt methods for each type of client what would be the best way to handle this?

Answer 1

I think interoperability with other clients is more dependent on the binding that the actual contracts. If the other clients and client languages that you will support can do SOAP, then sticking with the BasicHttpBinding provides the best support. For example clients using .NET 2 can still interact with a .NET 3.5 WCF server. There area also SOAP libraries for Java and other languages.

The server can just publish the WSDL, and the clients can then generate all your contract interfaces and types automatically in whatever language from the WSDL. That handles the ‘reuse’ of your data contract types.

If you want to venture away from SOAP, there are ways to do REST or Plain-old-XML or JSON with WCF, but it gets a lot more complicated from the server side…