If you work with WPF or Silverlight then you really should check out Rob Eisenberg presentation at MIX10 titled Build Your Own MVVM Framework. In that presentation he goes through a sample application that utilizes no code behind and no data binding or command binding expressions, all is hooked up through conventions and is driven solely from the presentation model. The sample app has about 500 lines of framework or infrastructure code that handles the view look up and convention based binding. I urge you to download it and really dig through it, it contains some awesome code and ideas.

But I will focus this blog post on one aspect of that sample app which is how Rob implemented async workflows. It might be a long post with a lot of code :)

Before I dig into what the above code does and how it works I need to explain the problem. Anyone who has worked with WinForms/WPF/Silverlight knows that backend calls and other long running work needs to be done on a background thread. However all UI updates needs to be done on the UI thread. If you use ThreadPool.QueueUserWorkItem and you want to notify the UI that something has updated (issue a NotifyPropertyChanged for example) then you need to marshal the the call via the WPF dispatcher so the NotifyPropertyChanged happens on the UI thread. Another option is to use the BackgroundWorker that automatically executes the event RunWorkerCompleted on the same thread that called RunWorkerAsync.

This does not look so bad, we still have all the code in one method thanks to the lambdas. But imagine that we need to fetch the game (another backend call) and open the game screen if the returned search result only match exactly one game. In that case we would need to new up another BackgroundWorker inside the RunWorkerCompleted lambda and then hookup DoWork and RunWorkerCompleted. The code would be very messy (nested lambda callbacks) and it would be hard to read the sequential flow of the process.

Coroutines to the rescue. Wikipedia definition reads:

Coroutines are program components that generalize subroutines to allow multiple entry points for suspending and resuming execution at certain locations

But C# does not have that! Well it kind of does. You can get the same effect if you define an enumerator using yield returns. In a method that returns IEnumerable you can use yield return. The C# compiler will turn that method into a state machine (to implement the enumerator). Each time someone calls MoveNext (which happens once each foreach loop) the execution of the method will continue until the next yield return.

Back to Robs sample app. The ExecuteSearch method above returns an IEnumerable of IResult, an interface that has an Execute method and a Completed event. The magic happens in how this enumerable is consumed, which is handled by the ResultEnumerator class:

This class might take some time to get your head around. What happens is that we take the first IResult by calling MoveNext, we then hook up the Completed event and then call the Execute method. The interesting thing is that the Completed event is hooked up the the same method that we are in. The result is that the first IResult controls when the next IResult is fetched (the next IResult won't be fetched until the one before executes the Completed event). Ok, think about this until you understand it :)

Now lets look at how we can use this. Lets try to create a IResult that executes a lambda in a background thread then executes the Completed event on the UI thread.

Looks better doesn't it? The BackgroundResult will block the execution of the method until the action completes which will fire the Completed event (which happens on the UI thread) which in turn will resume the execution of the ExecuteSearch method. The requirement to show the game screen when there is only one match is now much easier to handle as we can yield another BackgroundResult to fetch the game. The method logic happens in the sequential order that it is written, making it much easier to read, test and debug.

In the complete version he handles the case where there is only one match, in that case GetGame query is also issued to the backend. Before I end this post I will just highlight another interesting aspect of this sample and that is how Rob handles backend interaction. Instead of directly calling a IBackend service he returns an IQueryResult or ICommandResult which will handle the execution of the backend call and the thread marshalling. This improves the testability as the method will not require any mocking to test.

It's not trivial stuff, it takes some time to get your head around how the ResultEnumerator works and what it makes possible. But I think it is a pretty brilliant solution to keep complex async workflows in the same place and be able to read them sequentially. I am not sure if it is the same thing but if I remember correctly I think the C# team is looking at making this easier in C# 5 with an async keyword. Does anyone know how this implementation of coroutines compares to the async features in F#?

Getting started with doing coroutines is quite easy, but getting it right is very hard. In MindTouch Dream, we spent some considerable time making sure that 1) coroutines without results are reported as errors, 2) exceptions are propagated as expected to an outer context (or can be caught in place), and 3) exception stack traces capture the coroutine stack trace as well. That's a lot machinery and without it, programming coroutines becomes insanely complicated. If you want to learn more, check out MindTouch Dream, which is open source and available under Apache 2.0 license. Enjoy!

I was playing arround with this some and was wondering about a way to turn something like this into an extention method. I'v got a Datalayer that returns mostly List. I know that I can return an enumerable from that like