Need for separting DataContracts and ServiceContract in WCF

Visual Studio 2010 by default generates the following when I try to create a new WCF project. There is an interface for defining the methonds(Operation contracts in WCF terms) and an exclusive class which defines the Data that the definition of the service contract would use.

namespace iAMProxyService
{
    // NOTE: If you change the interface name "IService1" here, you must also update the reference to "IService1" in Web.config.
    [ServiceContract]
    public interface IProxyService
    {

        [OperationContract]
        string GetData(int value);

        [OperationContract]
        CompositeType GetDataUsingDataContract(CompositeType composite);

        // TODO: Add your service operations here
    }


    // Use a data contract as illustrated in the sample below to add composite types to service operations.
    [DataContract]
    public class CompositeType
    {
        bool boolValue = true;
        string stringValue = "Hello ";

        [DataMember]
        public bool BoolValue
        {
            get { return boolValue; }
            set { boolValue = value; }
        }

        [DataMember]
        public string StringValue
        {
            get { return stringValue; }
            set { stringValue = value; }
        }
    }
}

Now I am wondering if DataContract can help reduce any kind of dependancy between client and the server. That is, I feel that when I change the datacontract I don have to recompile the开发者_如何学编程 client code as it would be just having the interface(Service contract). Is my assumption correct or am I missing something!?

ServiceContract defines the operations and messages those operations consume and return

DataContract defines serialization from a .NET object to XML

DataContracts are used on ServiceContracts to describe the XML of a message in terms of its serialization class

Therefore, if you change a DataContract then it will impact the message the client is meant to send or receives in return - this may be a breaking change for the client.

However the DataContractSerializer is a very forgiving serializer (some might say too forgiving). If the sender sends data the receiver is not expecting then the serializer ignores that data. If the sender doesn't send data that the receiver is expecting then, as long as the data isn;t marked as IsRequired=true in the DataContract then the receiver just defaults in a value (e.g. 0 for an int)

So, if the change is a breaking change for the client either causing the serializer to fail or producing undesired side-effects from the serializer then you will have to change the client. If not then the client can continue to run unchanged

When you program to an interface, the implementation can change as long as it still implements the interface and you will not need to recompile the clients. However, it sounds like you are trying to change the interface for the DataContract. If you change that, you will (most likely) need to recompile. I say most likely because technically you can add to it and it shouldn't break anything (but it isn't adhering to strict schema compliance).

Here is an article on breaking versus non-breaking changes:

http://msdn.microsoft.com/en-us/library/ms731138.aspx

and best practices doing so:

http://msdn.microsoft.com/en-us/library/ms733832.aspx

and finally, a tutorial on what a DataContract is and how to use it:

http://www.wcftutorial.net/Data-Contract.aspx

The DataContract extends your service layer. It is one more interface that you work with. Therefore, you need to follow the same types of rules with the DataContract as you do with other interfaces. The client will be expecting certain things to be true of the DataContract (because it is a contract). If you make breaking changes to that contract, you are going to break the clients.