Where to place async web service methods

Dec 8, 2010 at 6:41 PM


I'm developing a Windows Phone 7 application using MVVM Light Toolkit. I fetch data to put in my ListBoxes and views by calling Web Services. I'm thinking of create a ServiceAgent class to handle the async web service calls but I'm not sure what is the best pattern to do this.

Should my exception handling be in the service agent? If a exception occurs how to give the user a message? The view is the place to pop-up a messagebox, the viewModel is the place to call the service agent, and the agent call the external service. Or is it? Could someone give me a code example on how to call a web service  and how the exception handling is could be done?

Hope someone could give me some code illustrating how you are doing this, thanks. 

Dec 9, 2010 at 10:18 AM


I did find a very good solution myself by looking at a video of Laurent Bugnion and copy some of his ideas as it was just what I was looking for.

I created a ServiceAgent with this Interface:

public interface IServiceAgent
        void GetNewsItems(Action<IEnumerable<NewsFeed>, Exception> callback);

So that in my ViewModel I can have a code like this:

 serviceAgent = new ServiceAgent.ServiceAgent();
                serviceAgent.GetNewsItems((feeds, error) =>
                    if (error != null)
                        //fire an event to notify the view to show a messagebox     
                    else this.NewsFeeds = Converters.ConvertToObservableCollection<NewsFeed>(feeds);

The this.NewsFeeds is a property in my ViewModel that the View is binding to and the result is perfect. This is very clean code and separate concerns very well.

I guess it's ok to have an event in the ViewModel for the View to subscribe for and show an appropriate message if something fails? This doesn't breake the idea of MVVM?

Thank you Laurent ;-) 

Dec 9, 2010 at 10:40 AM


Yep that looks good :)

Regarding ViewModel -> View communication: There are multiple patterns that work well.

- Very decoupled: using the Messenger to pass a message from the VM to the view. Some people I respect do that. In my opinion it's a bit overkill, because the VM and the View are pretty coupled by nature, but some people like the super decoupled model.

- Event: Tight coupling from the View to the VM, but at least the VM doesn't know who subscribes to the event. Fairly testable. I do that sometimes, especially subscribing to the VM's PropertyChanged event, for example when the View needs to start an animation instead of just showing a state.

- View services: Same pattern than with the IServiceAgent, but going up (to the view) instead of down (to the model). For instance, INavigationService, IAnimationService, IDialogService etc. Have the View implement it (if the service is simple), or an accessory class (for example the NavigationService). Inject this into the ViewModel (either with an IOC container, or simply through property injection) and voila. The VM can call MyDialogService.ShowDialog(...) and doesn't need to know what will happen. Very testable (with mocks), quite nice.

Makes sense?



Dec 9, 2010 at 5:34 PM

Hi Laurent

Thank you for your time and thoughts. My first thought is that the first pattern is the cleanest and easiest to design, read, maintain and with less code. Is that right?

Doing it with an event may be OK once, but I expect to use this all over my application so I think this is not the way to do it.

Your third suggestion is maybe the way you like best? But it will be more code and maybe diffucult to read with multiple services?

I'm pretty new to Silverlight so could you give me short description of the Messenger pattern?


Thanks again, and thank you for this great toolkit!!!!!

PS! I see that Prism 4 has been released with support for WP7, but I'll stick with MVVM Light Toolkit because it keeps things simple. Are you comming with an update to soon?