Introduction

Silverlight-era async code often relied on callback-heavy event patterns generated by service proxies. That worked, but it quickly became hard to compose, cancel, or test once multiple requests and UI updates were involved. Reactive Extensions, usually called Rx, improved this by turning event-based operations into composable observable streams.

The Problem with Event-Based Service Calls

Older Silverlight service clients often exposed methods like GetOrdersAsync() and paired them with completion events like GetOrdersCompleted. That model spreads control flow across separate methods and encourages flag-heavy UI code.

A typical event-based version looked like this:

1var client = new OrdersServiceClient();
2
3client.GetOrdersCompleted += (sender, e) =>
4{
5    if (e.Error != null)
6    {
7        StatusText.Text = e.Error.Message;
8        return;
9    }
10
11    OrdersGrid.ItemsSource = e.Result;
12};
13
14client.GetOrdersAsync(customerId);

That is manageable for one request. It gets harder when you need retries, throttling, chaining, or cancellation.

Wrapping the Async Pattern with Rx

Rx lets you convert event-based async calls into IObservable<T>. Once the service call is an observable, you can compose it with other streams and keep the logic declarative.

One common approach is to wrap the completion event manually:

1using System;
2using System.Reactive.Linq;
3
4public static class OrdersClientExtensions
5{
6    public static IObservable<GetOrdersCompletedEventArgs> GetOrdersObservable(
7        this OrdersServiceClient client,
8        int customerId)
9    {
10        return Observable
11            .FromEventPattern<GetOrdersCompletedEventHandler, GetOrdersCompletedEventArgs>(
12                h => client.GetOrdersCompleted += h,
13                h => client.GetOrdersCompleted -= h)
14            .Take(1)
15            .Do(_ => client.GetOrdersAsync(customerId))
16            .Select(evt => evt.EventArgs);
17    }
18}

Then you can subscribe to the result:

1var subscription = client
2    .GetOrdersObservable(customerId)
3    .ObserveOnDispatcher()
4    .Subscribe(
5        e => OrdersGrid.ItemsSource = e.Result,
6        ex => StatusText.Text = ex.Message);

The important shift is that the request is now a value-producing stream, not just a callback hook.

Composing Multiple Async Steps

Rx becomes more valuable when the workflow has multiple async stages. For example, suppose you first fetch a customer and then use that customer id to fetch orders.

1var workflow =
2    customerClient.GetCustomerObservable(userName)
3    .SelectMany(c => ordersClient.GetOrdersObservable(c.Result.Id))
4    .ObserveOnDispatcher();
5
6var subscription = workflow.Subscribe(
7    e => OrdersGrid.ItemsSource = e.Result,
8    ex => StatusText.Text = ex.Message);

Without Rx, this usually becomes nested event handlers. With Rx, the flow stays linear and readable.

Cancellation and Lifetime Management

One practical benefit of Rx is that subscriptions are explicit. You can keep the returned IDisposable and dispose it when the view is unloaded.

1private IDisposable _subscription;
2
3private void LoadOrders()
4{
5    _subscription = client
6        .GetOrdersObservable(42)
7        .ObserveOnDispatcher()
8        .Subscribe(
9            e => OrdersGrid.ItemsSource = e.Result,
10            ex => StatusText.Text = ex.Message);
11}
12
13private void UserControl_Unloaded(object sender, RoutedEventArgs e)
14{
15    _subscription?.Dispose();
16}

In UI-heavy Silverlight code, this helps avoid stale callbacks updating controls after the view is gone.

Error Handling Becomes Centralized

With raw event handlers, each callback usually needs its own error path. Rx gives you one error channel through Subscribe.

You can also add retry or timeout behavior in one place:

1var subscription = client
2    .GetOrdersObservable(customerId)
3    .Timeout(TimeSpan.FromSeconds(5))
4    .Retry(2)
5    .ObserveOnDispatcher()
6    .Subscribe(
7        e => OrdersGrid.ItemsSource = e.Result,
8        ex => StatusText.Text = "Request failed: " + ex.Message);

This is the kind of policy logic that gets messy fast in plain event code.

Why This Was Useful in Silverlight

Silverlight apps were UI-driven and network-heavy, but they predated the modern async and await style that later made asynchronous .NET code much easier. Rx filled that gap well because it:

• reduced callback nesting
• made UI-thread marshaling explicit with ObserveOnDispatcher
• gave one place for retry, timeout, and error handling
• made multi-request workflows easier to compose

Today, in newer .NET UI stacks, async and await are usually the first choice. But for Silverlight or older event-based APIs, Rx was and still is a strong simplification tool.

Common Pitfalls

• Subscribing to an event stream without unsubscribing or disposing the subscription.
• Forgetting ObserveOnDispatcher() before updating UI controls.
• Wrapping the event but still keeping most business logic in nested callbacks.
• Using Rx for one trivial request without benefiting from composition.
• Assuming Rx cancels the underlying service operation automatically unless the underlying API supports that behavior.

Summary

• Rx helps turn Silverlight service callback patterns into composable observable sequences.
• This removes a lot of event-handler nesting and scattered control flow.
• 'ObserveOnDispatcher() is important when the subscription updates UI state.'
• Rx becomes especially valuable when chaining requests, handling errors, or applying retry and timeout rules.
• In legacy Silverlight code, Rx was often the cleanest bridge from event-based async code to something more maintainable.