best practice for return value in WCF services

I have a WCF service sitting in the cloud. And my application makes several calls to this WCF service. Is it a best practise: 1] to always use return value as bool which indicates if the operation was sucessful or not. 2] returning the values you meant to retur开发者_如何学编程n as the OUT parameters

I would:

• return an atomic value (bool, string, int) if appropriate

• return a complex type (a class instance) if I need to return more than one value - make sure to mark that class with [DataContract] and its properties with [DataMember]

• a SOAP fault FaultException<T> when an error occurs; the <T> part allows you to define your own custom error classes, and again - don't forget to mark them with [DataContract] / [DataMember] and declare them as FaultContract on your operations

1] to always use return value as bool which indicates if the operation was sucessful or not

• Yes, if the operation isn´t time consuming AND the return status is always relevant: Waiting on a return value can affect both client and service host(server) performance/scalability. Ex. in a Request-Responsecall, Requests can keep connections open for a long preriod of time waiting for operation completion. You could implement in a way similar to "HTTP 202 Accepted" status code usage(i.e operation received arguments and has started(patially), but does wait for the completion)
• No, if the operation logic only makes sense if synchronous.
• No, if you are keen on refactorability/maintainability ex. when you want to return include an error message/code in the return.

2] returning the values you meant to return as the OUT parameters

• Yes, this makes the service operation more wsdl compliant and easy to read.