Using Reqest / Response classes on a WCF contract - is that a good idea?

Question

We have a situation where we might want to pass client information on every call we make on a WCF operation. At the response level, we want to have fields to indicate success and an error message.

Is it a good idea to use a Request class and a Response class? I was looking into two operation

OpeationResponseData Operation(OperationRequestData input);

I don't use OpeationRequest because that has issues with wsdl.

I will have base classes that will have the common fields each operation will need. For example:

OperationResonseData : Response 
OperationRquestData : Request

Another option is to use

Request<T> and Response<T>

I was wondering if there were a better way, or if there were some guidelines on this issue...

Answer 1

WCF's base messaging architecture, the Message class, already has support for all of these concepts built in.

• For information that is supposed to be passed with each logical operation, you use headers.
• For errors you throw FaultException or, if you want to return a custom data structure with your error, you throw FaultException. Being that errors result in faults, the lack of a fault indicates success. If you want to return details about your success then your operation should return a custom data type, otherwise you can just return void.

How this maps to what's sent across the wire depends on what formatting stack you're using (SOAP, REST, etc.). The default stack is SOAP and, being the blueprint for WCF, has a very natural mapping: headers map to SOAP headers and faults map directly to SOAP faults. For REST headers can be mapped as HTTP headers and faults would result in a 500 status with a message.