4

I've seen several different ways to design WCF services, and it seems some developers prefer parameter wrappers while others favor 'naked' parameters. To explain what I mean, consider the following service interfaces:

'Naked' Parameters

[ServiceContract]
public interface IService
{
    [OperationContract]
    string[] GetValuesByType(string groupName, ValueTypeEnum valueType)
}

Parameter Wrappers

[DataContract]
public class GetValuesByTypeRequest
{
    [DataMember]
    public string GroupName { get; set; } 

    [DataMember]
    public ValueTypeEnum ValueType { get; set; }
}

[DataContract]
public class GetValuesByTypeResponse
{
    [DataMember]
    public string[] Result { get; set; } 
}

[ServiceContract]
public interface IService
{
    [OperationContract]
    GetValuesByTypeResponse GetValuesByType(GetValuesByTypeRequest request)
}

I suppose there are cases where parameter wrappers make it easier to maintain the service over different versions of the software, since you can control serialization of each member a bit more directly than you can with the first method. But to be honest, parameter wrappers just seem like a lot more code for very little benefit. Am I wrong here?

9

You are correct, in that in terms of how the code will change over time, I typically lean toward parameter wrappers so that later, when I need more information to perform the same function when adding a new feature, I can preserve signatures, and add one more property to the existing wrapper object.

When it comes to building communication contracts like you do when working with WCF, this will preserve the contract, and allow clients working with the old object to continue to function as they used to -- they just won't get the benefit the new property offers. Serialization will simply ignore the property, and happily pass the object along. As clients are updated to "know about" the new property, they can migrate their code accordingly.

If you were to change the signature of that method by adding a parameter, you will break the contract you have with all your clients, forcing them all to synchronously release updates with your signature change.

If your code has clients for which you do not control the deployment cycle, do future you (or future developers on your code) a favor and design with parameter wrappers. If you control all client code and deployments and can force them all out at once, then it probably doesn't matter. But in the grand scheme of things, it's not a ton of extra code and it's a good habit (IMHO).

  • Thanks for the detailed answer. I'll begin using this pattern from now on in my service contracts. – p.s.w.g Mar 5 '13 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.