Duplex callbacks or client-side streaming for WCF click clients

I have a certain service where specific functions will take longer than others, sometimes they may take a few seconds to return. To prevent the client interface from being blocked when this happens, which is the preferred solution:

  • Use a duplex channel and simply use callbacks to update the user interface when receiving data.
  • Use a separate thread to invoke the service and simply use request-response operations, and then update the ui thread when returning data.

Which solution is better, especially if interoperability is preferable, but not absolutely necessary and, in your opinion, which one is faster (and cleaner) for implementation and support?

+4
source share
2 answers

If you implement callback contracts, you remove the need for the client to execute multi-threaded code. This may not be a significant advantage when working with .Net clients (since VS will automatically generate asynch proxy code for you), although it may be useful when working with clients of other platforms / languages.

Which one is cleaner? Well, it depends on whether you are a client or server developer. If, as I suspect in your case, both of you, and you can simply use .Net for the client and server, then I will probably be tempted to avoid callbacks. If you meant that the service calls where it takes 45 seconds, then I would say that you need to translate the contracts, this is really subjective, but if I had to stick my neck out, I would say that if the answers take more than 5 seconds, then it's time to move on to callbacks.

+5
source

You must implement CallBackcontract .

Here is an example .

0
source

All Articles