wcf architecture design. re: return values.

Question

Hello and thanks for your opinion.

I am creating a webservice. This webservice will accept a customer and the customers accounts along with a couple other related objects and attributes and such.

When the webservice recieves a request, I attempt to process it.
If there is no error I simply just return. If there is an error, I throw it.

I'm wondering if this is the best approach, or if I should modify my design so that I return a bool as the response, or even create a response object, that maybe contains the original request object plus a status and if error, a list of errors (ie: Missing Fields, Invalid Fields, ext).

Which return method would you incorporate in your design?
1) Just return if no error, Throw error if error 2) bool success 3) Response object (containing original request object? and detailed results)?

Thanks for any suggestions. Steven

Answer 1

hello Steven,

i think that it depends on who will use this service,

if you are the only one that will use this service i recommend you to return nothing(or the original request) and throw exceptions if something is wrong.

if the service is for public use, you should return some response object that will contain errors, and some other relevant data.

good luck

Answer 2

I would say that it depends on what the 'error' is. If the error is validation-related but expected in the normal course of events e.g invalid user credentials being passed to a service that provides user authentication, then returning an enum value that indicates the request result (Success, Failure, etc) is probably OK. However if the error is due to input that should not happen in the normal course of events, then I would suggest you throw a fault from the service operation. Throwing a fault indicates that the client app is in error and has provided input that the service does not know how to deal with. You can register particular fault contracts with a WCF service operation so a client app knows the operation may throw one of a number of faults under particular circumstances. The client app should provide exception handlers for these faults and take action if one is thrown, otherwise it will terminate unexpectedly.

As a basic rule of thumb, I would say throw faults under exceptional circumstances e.g. where the client has provided input that the service operation does not expect to receive. If the client has provided information that is incorrect but the service operation is progammed to handle, return a status code or information in the response message.

Answer 3

As a general rule of thumb: if the circumstances do not allow you to complete the request successfully, throw an exception. If you want to communicate back other information, such as an order number etc. then use a return value. It is not generally a good idea to signal back a complete failure via a boolean return value - that could be ignored / not checked by the caller.

Now since it's a WCF service that is being used by outside sources, you shouldn't just throw an exception - that's a .NET specific thing - but rather throw a SOAP fault. You should declare these faults as part of your service contract on every operation your service offers, by adding one or more FaultContract attribute to your operations:

[FaultContract(typeof(MyFault1))]
[FaultContract(typeof(MyFault2))]
[OperationContract]
void MyOperation()

You can do this easily in .NET WCF by throwing a FaultException or a more specific FaultException (a generic variant in which you can specify the exakt type of fault).

Marc