Asynchronous architecture

Question

I have a C# library that is surfaced through a webpage UI. There's of course the UI layer, which makes calls through a business logic layer, which in turn hits the data access layer to retrieve the data. The data is actually retrieved via a web service which has the capability to query data asynchronously.

I'm starting to learn how to deal with requests asynchronously to both speed up page time (grabbing multiple items from the web service as soon as I can with multiple threads), and for scalability by threads not being tied up all the time.

Given the three-tier architecture of my code, would this mean that pages asynchronously make calls through the business layer (and therefore speed up by making concurrent requests), and the web service in the data layer in turn would also make its requests asynchronously? The logic of juggling all the callbacks is hurting my brain. Are there any resources out there for this type of approach?

Answer 1

If you can stand to introduce a new language, F# is terribly good at writing asynchronous code, one of its main strengths, IMHO, aside from its conciseness. Writing async code looks almost exactly like linear non-async code!

Related links:

• Beyond Foundations of F# - Asynchronous Workflows
• An introduction to F# (video)
• Concurrency in F# (video - excellent short case study on speeding up an existing real-world C# insurance processing system with selective introduction of F# replacement modules)

If you don't want to introduce a new language, here is a technique for using iterators to simplify your code:

• Asynchronous Programming in C# using Iterators

Answer 2

I guess you have two areas to handle callbacks from:

• Data Layer -> Business Objects
• Business Objects -> Presentation Layer

For the first one, I would use code generation to automatically create the aysnc and callback logic for all the methods. If you have alot of classes that are pretty close to being the same then this work quite well.

For the second area, I tend to use databinding to 'automatically' update the UI as the objects underneath are populating.

Answer 3

There is a somewhat useful concept called Future<T>, which represents a unit of an asyncronous work to be done in future.

So, in simple words, at the beginning of some action (like app start or page load) you can define, which values you will need in future and let the background threads to compute them for you.

When your user demands a specific value, you just ask for it from the according Future<T>. If its already done, you get it immediately, otherwise you'll have to block your main thread, or somehow inform the user that the value is still not ready.

Some discussion of that concept you can find here.