Request and Response objects and WCF versioning

I'm in the process of designing my first "proper" WCF service and I'm trying to get my head around how to best handle versioning of the service.

In older ASMX web services, I would create aMethodNameRequest and MethodNameResponse object for each web service method.

A request object would really just be a POCO wrapper around what would typically be in the method parameters. A response object might typically inherit from a base response object开发者_高级运维 that has information about any errors.

Reading about WCF and how the IExtensibleDataObject, FaultContractAttribute and Namespacing works, it seems that I can revert back to using standard parameters (string, int etc) in my method names, and if the service is versioned, then ServiceContract inheritance can provide this versioning.

I've been looking into http://msdn.microsoft.com/en-us/library/ms731060.aspx and linked articles in that, but I was just looking for a bit of clarification.

Am I correct in thinking that dispensing with the Request/Response objects is more ideal for WCF versioning?

EDIT: I just found this article which suggests using explicit request/response object: http://www.dasblonde.net/2006/01/05/VersioningWCFServiceContracts.aspx

---

I don't agree that dispensing with Request/Response objects is that way to go.

There are obvious benefits of coding with messages:

• you can reuse them, which avoids pass 5 ints and 3 strings to a number of different methods.
• the properties are named and so can be reliably understood, whereas a parameter that is passed by value through multiple tiers could be confused, and so on.
• they can be proper objects rather than just data containers, if you choose - containing private methods, etc

But you are really asking about versioning. Don't forget that you can version the messages within your service contracts. The classes in assembly can have the same name provided they are in different namespaces (e.g. v1.Request and v2.Request), and they can both implement a required interface or inherit from some base object.

They also need to be versioned for your service consumer, which can be done with xml namespaces; I've typically put the service contracts (the operations) in a namespace like http://myapp.mydomain/v1 and the messages (the request and response objects) in http://myapp.mydomain/v1/messages.

One gotcha with this approach is that if you have an operation, call it Submit, in the http://myapp.mydomain/v1 namespace then by convention / default the soap objects SubmitRequest and SubmitResponse will also exist in the same namespace (I don't remember what the run-time exception is but it confused me for a while). The resolution is to put message objects in another namespace as I've described above.

---

See "Versioning WCF Services: Part I" and "Versioning WCF Services: Part II".