The pace at which Microsoft are releasing new technologies at the moment is little short of astonishing. I had heard about the reactive framework a while ago but I didn't know it had actually shipped in any form yet. I ended up finding a use for this for the first time yesterday on a Silverlight project when I noticed that System.Reactive.dll had been installed as part of the Silverlight toolkit. On this app I'm creating a domain layer that will be shared by the Silverlight application on the client side and an asp.net application on the server side. I'm using a shared code approach for this at least until Silverlight 4 is released (via Visual Studio's 'Add existing item -> Add as link'). I had originally thought this would preclude me from using the reactive extensions in the shared domain model but then I stumbled across this: http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx. Basically Microsoft have already released the Reactive Extensions for 3 platforms - Silverlight, .NET 3.5 sp1 and .NET 4.0. So I was able to download the .NET 3.5 sp1 version and use the Reactive framework in both versions of my domain layer as I wanted to.

For a basic overview of the reactive framework, check out the Microsoft devlabs site (http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx). Here's the most pertinent quote from the front page of the site:

Rx is a superset of the standard LINQ sequence operators that exposes asynchronous and event-based computations as push-based, observable  collections via the new .NET 4.0 interfaces IObservable and IObserver.  These are the mathematical dual of the familiar IEnumerable and IEnumerator interfaces for pull-based, enumerable collections in the .NET framework.  

Here’s a simple example (with most of the non-pertinent code removed from the classes) of how I’m using the IObservable interface where I would otherwise use a standard CLR event pattern.

public class Plan
{
    private readonly IList _selectedSurveyElements;
    private readonly Subject _surveyElementAdded;

    public Plan()
    {
        SurveyElementAdded = _surveyElementAdded = new Subject();
        _selectedSurveyElements = new List();
        _assetPlans = new List();
    }

    public IObservable SurveyElementAdded { get; private set; }

    public virtual IEnumerable SelectedSurveyElements
    {
        get { return _selectedSurveyElements; }
    }

    public void AddSurveyElement(SurveyElement surveyElement)
    {
        _selectedSurveyElements.Add(surveyElement);
        _surveyElementAdded.OnNext(surveyElement);
    }
}

public class AssetPlan
{
    private readonly IList _surveyElementPlans;

    public AssetPlan(Asset asset, Plan plan)
    {
        Asset = asset;
        Plan = plan;

        _surveyElementPlans = new List();

        plan.SurveyElementAdded
                .StartWith(plan.SelectedSurveyElements.ToArray())
                .Subscribe(x => _surveyElementPlans.Add(new SurveyElementPlan(x, plan)));
    }

    public Asset Asset { get; private set; }
    public Plan Plan { get; private set; }

    public IEnumerable SurveyElementPlans
    {
        get { return _surveyElementPlans; }
    }
}

The ‘interesting’ part here, is in the constructor for AssetPlan – the elements currently attached to the plan are converted to an IObservable and then concatenated with any elements that are added to the plan in the future (plan.SurveyElementAdded) and all of them are operated on inside the lambda. This would take more lines of code and be less ‘declarative’ using an event pattern.