Reputation: 1566
Suppose I have a C# web application and a C# WCF service floating out there somewhere. They operate on a contract like this:
[ServiceContract]
public interface IRemoteDeliveryService
{
[OperationContract]
Customer GetCustomer();
}
...with Customer being:
[Serializable]
public class Customer
{
public string Name { get; set; }
public int Age { get; set; }
}
Now suppose the web application is updated with a feature that is not relevant to the WCF service, but causes Customer to be extended.
[Serializable]
public class Customer
{
public string Name { get; set; }
public int Age { get; set; }
public int Income { get; set; } // new!
}
From experience, if the service reference and the service is not immediately updated, users will start getting this error until the WCF service is pushed to reflect the new object: Error in line 1 position 21175. 'EndElement' '(whatever)' from namespace 'http://schemas.datacontract.org/2004/07/(whatever 2)' is not expected. Expecting element '_whatever3'.'
I've done all I can think of to avoid this situation. I removed a number of dependencies on complex objects, but some (like Customer) are so important they're hard to take out of WCF communication entirely. I've tried blocking properties from being serialized, but WCF does it anyway.
What can I do to make the WCF service more tolerant of prospective extra properties introduced by the web app? I can modify both service and web app, just as long as modifying the service minimizes future excess redeployments.
Upvotes: 1
Views: 95
Reputation: 17327
Use Data Transfer Objects (DTOs). Those classes should belong to the service and should only change if the service is being updated. Map business objects, entities, models, etc into your DTOs using something like AutoMapper.
Layers of separation (and make sure the layers don't bleed into each other), will allow you to make changes like the one you describes without impacting the other layers.
Upvotes: 2