Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from codereview.stackexchange.com Mar 2 '13 at 20:50

This question came from our site for peer programmer code reviews.

1 Answer 1

up vote 7 down vote accepted

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).

share|improve this answer
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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