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

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:

[OperationContract(Name="GetPerson"]
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.

Previous Page