RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Best Practices for Handling Change in Your WCF Applications : Page 3

Change is inevitable, but with a little planning and a few key principles, you can minimize the impact that changes have on your WCF service consumers.


Service Contract Changes

Once again, all service contracts should follow the best practice of using both the Name and Namespace parameters on the ServiceContract attribute. An updated version of the Person service contract might look like this:
[ServiceContract(Name="PersonService", Namespace="http://services.mycompany.com/2009/05/25"]
public interface IPersonService
As with the data contract, using the Name isolated the service consumer from the actual interface name, allowing the internal implementation to change as needed. The addition of the Namespace allows you to version the contract at some point in the future. Remember that new versions also require new endpoints.

You can add operations to service contracts without breaking existing consumers. Consumers will simply ignore the new operations. Removing operations, on the other hand, will break existing consumers. As with all breaking changes, the removal of an operation requires a new version along with a new endpoint.

Operation Contract Changes

As with the service and data contracts, you should use the Name parameter with the OperationContract attribute:
Person GetPerson(int personId);
The consumer is, once again, isolated from changes in the internal implementation.

Finally, the last change to consider is in the signature of an operation contract. This is a breaking change for which you have two solutions: create a new version or add a new operation to the service contract.

Honor Your Commitments

Change is inevitable, but with a little planning and a few key principles, you can minimize the impact changes have on your WCF services. Always remember that when you release a service, you make a commitment to the service consumers to honor the contract. Making changes to an existing contract is bad form.

To that end, keep some best practices in mind:

  1. Always use the Name and Namespace parameters on all contracts.
  2. Always use the Order parameter on data members.
  3. Implement the IExtensibleDataObject on all data contracts.
  4. Use namespaces for contract versioning.
  5. Always remember that new versions require new endpoints.
  6. When using strict schema validation, do not change contracts. Create new versions.
  7. When removing an operation from a service contract, create a new version.
  8. When changing the signature of an operation, create a new version.

With these practices in mind, you can make change just a little easier to dealing with for yourself and your service consumers.

Steve Stefanovich has spent over a decade with RDA Corporation as a developer and principal architect focusing on custom application development using Microsoft .Net and SharePoint technologies. Steve is a frequent contributor to RDA's Architecture and Collaboration blogs.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date