Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Best Practices for Handling Change in Your WCF Applications

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.


advertisement
hange is the one constant you can depend on: Requirements change, environments change, and processes change. Together, these factors ensure that your WCF services will change as well. Fortunately, you can make some basic design decisions at the outset that will make these changes much less disruptive to your service consumers and, in the end, to yourself.

This article explores not only the upfront decisions you can make to minimize changes, but also the strategies you can employ to deal with any big changes that your service consumers may not have foreseen, but that you know are coming.

Defining Change

Before diving into how to deal with change, it makes sense to explain what change means in a WCF-based service. The following actions (listed by type of contract) constitute changes:
  • Data contracts
    • Adding a data member
    • Removing a data member
    • Renaming a data member
    • Changing the type of a data member
  • Service contracts
    • Adding an operation
    • Removing an operation
    • Renaming the service contract
  • Operation contracts
    • Renaming the operation
    • Changing the signature of an operation



These changes might be the result of new business requirements, hardware consolidation, business mergers, new regulations, or any number of other external factors. The bottom line is that when something outside the developer's control changes, the software must adjust. Dealing with change in the WCF world is a constant case of good news/bad news. You can handle some scenarios quite easily, while others will lead you to give the dreaded "yes, but…" response.

Versioning and Change in WCF

In the .NET world, one of the first considerations that come to mind when dealing with change is versioning. You can version assemblies to allow for unforeseen or breaking changes in later revisions of a component. That way, the affected clients can continue to utilize an older version of an assembly and you can avoid the headaches associated with a breaking change.

The logical question then is 'does WCF support versioning?' The answer is that dreaded "yes, but…" When you create a data contract in WCF, the contract generates an XML schema. Consumers reference this schema and use it to generate a proxy class. The data is not, strictly speaking, validated against this schema going forward. As you will see, this can sometimes cause unexpected and frustrating behaviors for service consumers.

Before diving into specifics, familiarize yourself with the following sample service. It provides the basis for the discussion in the remainder of the article.

namespace SampleService { [ServiceContract] public interface IPersonService { [OperationContract] Person GetPerson(int personId); [OperationContract] void UpdatePerson(Person p); } public class Person { private string _firstName = string.Empty; private string _lastName = string.Empty; [DataMember] public string FirstName { get { return _firstName; } set { _firstName = value; } } [DataMember] public string LastName { get { return _lastName; } set { _lastName = value; } } } }



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap