Hi, I posted this question on a newsgroup a couple of days ago but there has been very little response.
What do people think when they want to call a web service from a winforms presentation layer? What I'm asking is how many people out there automatically think asynchronous web service calls when doing a Windows forms UI talking to a web service backend?
I would be interested in hearing your views on this,
does everyone still use an RPC style when calling to a web service, even when the web service is your own??
I have an application that is designed to be istributed, it has a windows forms UI and uses web services for the 'middle tier'. At present I'm trying to do all 'service' calls asynchronous. Am I making more work for myself?
Do Microsoft have a best practise for this?
Can there be any justification in calling a web service synchronously (apart from it makes the client UI code simpler!)?
I'm not asking how do make asynchronous calls, more are they worth it?
If you don't make it async, your app will become non-responsive during your ws call. Since it's a WinForms app, people expect more out of it than a browser. They don't like seeing their desktop app blanked out when they click a button.
Luckily, .NET makes async calls almost trivial. I think the effort is well worth the benefit.
I agree with you. I haven't actually written to large winforms app that wasn't async so I don't really know how bad it is calling things on the UI thread.
Anyone else had experience of this?
It's been a while (.NET 1.0) and I'm going off memory, so consider the source. But VS studio will generate the async method for you, and when you call this async method, you provide a callback. Your UI thread returns right away, of course, & the async
method will spawn a new thread to call the ws & wait for the result, then call your callback.
The tricky part is, when your callback is called, it's not by the UI thread, so you'll have to use Control.Invoke (this.Invoke) in your form to call yet another function. That last function is guaranteed to be called by your UI thread so you're set to update
I remember reading somewhere that this processed is simplified, but I'm not sure.
Doing possibly lengthy (anything over the internet) operations are justified by asynchronous calls when it comes to winform application. People simply expect their applications to stay responsive. You will really make a better product when your app stays
responsive when it’s waiting for a webservice to complete. So to answer your questions asynchronous calls are worth the effort.
By implementing the simplified service agent pattern you can write very responsive winform applications.
Up to this point my winforms app WS calls have all use the Async Beginxxxx methods that exist in the proxy generated code. Can you think of anything wrong with this? Is there a better way?
That's the recommended solution, me thinks. Of course, remember that if you want to access any UI code from the asynchronous callback, you'll need to use Control.Invoke to marshall it back to the UI thread.
Alternatively, you could create a new thread yourself and call the webservice methods synchronously in that thread. If you need to make a bunch of web service calls in sequence this approach could simplify your code a bit. You
still need to use Control.Invoke when accessing UI stuff from this new thread.
I have found the UI handling is becomming the harder part of the application. Marcel kindly pointed me to a blog that described a way of automatically switching to the UI thread once the web service call completed, however, this doesn't work that well for me
because it relies on the class calling the web service to be a UI control. In my situation I have a 'controller' class that separates the form logic from the UI form handling. It is this controller that communicates with the 'serviceagent'. I must admit, I
might change this serviceagent class to look for a specific interface that my controllers implement as well as the callers base class being Control.
All this means that my UI code has to deal with two extra things above what is would have to in the sync world.
1) I must ensure the application features that may interfear with the current async operation are disabled.
2) I must make sure all my UI classes have thread safe (read thread switching) public methods if an update is to be made on the UI.
Don't get me wrong, I'm all for async message based programming, I'm just explaining my experience.
If you're worried about polluting your class library with references to Control, you can always use ISynchronizeInvoke instead. That's the interface that provides the Invoke method - Control implements it. Plus, if you have any other thread-sensitive systems
(maybe ones communicating with legacy single-threaded code?) later on that you want to use, just implement ISychronizeInvoke and you're gold.
Thanks for all yor comments.
I think I'll look in to this interface.
I would be interested in hearing your views on this, does everyone still use an RPC style when calling to a web service, even when the web service is your own??
I'm using a synchronous model, mostly because I'm far too lazy at this point to implement the obviously-better asynchronous model. Once I have a chance to spend some time with it, I'll be checking out asynchronous webservice calls.
Learning to call a service asynchronously is something you just have to deal with. Otherwise, your app's UI can lock up for 30 seconds or more when there is trouble with the network.
I make sure to keep the result of the "BeginXXX" method and can cast it to a WebClientAsyncResult. This lets you cancel the async method. For example, you can call an async method from a Form, and close the Form before it's finished. If you don't cancel the
method, it will try to make a callback to the Form and throw an exception.
when it comes to gui coding - i recommend it..
you can get around it with your threading techniques.. but.. asynch should suffice for most cases.. check it out.. its rather straight forward to use..
just gets a little tricky when you start going nuts with - like trying to make requests to 100000 of servers at once or something (dont ask where that came from)
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.