WPF Client - Should I make calls to WCF service in background thread?

Question

I have a WPF client that makes calls to 2 WCF services.

One service is for querying only and one service is for commands (CQS pattern).

How should I make the calls to the commands service ?

I read somewhere that all the operations in the command service must be 'One-Way', because they should not return any values. And that if something went wrong - the operation should throw a 'FaultException' to the client.

But if the commands are all One-Way - what do I do in the client ?

Say I have an 'AddProduct' window in the WPF client, and I enter information and press 'Save'.

I now call 'AddProduct(Product)' in the service, but :

1. Should it close the window ?
2. Should it wait for 10 seconds to see if there wasn't any FaultException ?
3. Should the operation not be 'One-Way' ? If so - should all operations in the command service return some type of generic 'Result' object with 'succeeded' or 'failed' ?
4. If section 3 is 'Yes' - should I call the service in a seperate thread and 'disable' all the controls on the window until I get a response back from the service ?

Thanks.

Answer 1

I would say option 3 is the way to go, but you probably do not need the generic Result object to communicate errors to the client. As you might know, exceptions are not serialized in the SOAP message so you won't get any of the usual .NET exceptions on the client side. On the other hand, you can still take advantage of SOAP Faults by catching FaultException on the client. Accordingly, if no exceptions were caught on the client, then everything went well.

For more information about fault exceptions and how you can use them to your benefit, take a look at:

Specifying and Handling Faults in Contracts and Services

Answer 2

I think using On-Way is fine but you have to be aware of some one-way call characteristic. If you care and can handle service exceptions then #4 is fine option.

One Way message - Once the client issues the call, WCF generates the request message but no correlated message will be ever returned to the client. Any exceptions thrown on the service side will not make it to the client.

One thing that you should have on is the reliability on your service so side so that you can insure that request has been delivered to the service.

When there is no transport session (basic or wsHttp binding) if exception occurs during the call of one-way operation client will be unaffected and it can continue sending calls on the same proxy instance.

If there is a presence of transport session - service side exception will fault the channel hence client will not be able to re-use proxy for sending more calls. This can give you an option to discover if something went wrong on the server side (but not what went wrong). Although, if service is using a FaultContracts you can still get into situation where client is unaware that something went wrong.

When service throws an exception listed in service side fault contract this will not fault the communication channel hence the client using one-way contract cannot detect communication failure.