History
Silverlight 4 and WCF RIA Services mark the coming of age for the Silverlight platform and for the creation of Rich Internet Applications as a whole.
Silverlight: the idea is not new but the ability to leverage developer knowledge by reusing the desktop programming framework is.
WCF RIA is a communication framework and as such, it is not new but the integration of the developer tooling and automatic code generation is a marked improvement on all that have come (and gone) before.
What Do We Need?
There is a pressing need for composition – both in terms of UI composition and of application composition. Composite Application Block (aka Prism) was the first implementation from Microsoft that attempted to deal with this feature.
To aid testing, mocking frameworks and loose coupling we also have a need for an integrated IoC solution.
Next we must wait to find out whether the Coordination and Concurrency Runtime (CCR) from the Microsoft Robotics Toolkit will not only be migrated to .NET 4 but also finally put in an appearance on the Silverlight platform. For those of you who have used this framework in robotic/desktop applications will realise that it represents a different approach to parallel programming which also turns out to be very scalable and possess high performance…
We also need a version of SQL Compact Edition for Silverlight – either downloaded as an XAP or available to out-of-browser applications via COM (actually it is possible to hook SQL Compact through Silverlight 4 COM interop – at least it looks like it is possible! I have not yet investigated whether SL4 COM is capable of talking to non-dual/automation COM objects yet…)
Finally we need a version of the Sync Framework for Silverlight (apparently this is in the pipeline) so we can stop writing the synchronisation code…
Yet Another Silverlight Framework
I’m not sure we need yet another Silverlight framework but I know I certainly need something that fills the gap between what I have and what I need.
To this end, I will be creating Yet Another Silverlight Framework that is the lovechild of the following bits and pieces;
1. Built on a foundation of IoC provided by Microsoft Unity v2. The base IoC feature-set is augmented with support for Lazy enumerations and is fully integrated with the .NET Framework v4 composition features exposed by System.ComponentModel.Composition. Encapsulating code originally part of the MEF Contrib CodePlex project (http://mefcontrib.codeplex.com/). Composition is a first-class citizen here. 
2. Next I added the composition features of Prism – in particular the module and region management for creating composite UI. The prism source was pretty much lifted as-is.
3. Next I added the Model-View-ViewModel features of the excellent SilverlightFX framework (http://projects.nikhilk.net/SilverlightFX). In so doing, this framework was refactored to take advantage of Silverlight 4 language features and the proprietary IoC replaced in favour of Unity.
4. Next we will integrate a message processor that is capable of queuing operations to a domain service. The queue is actually a priority queue so that different classes of message are handled with differing levels of promptness. The purpose of this queuing logic is two-fold. Firstly it simplifies the code needed to communicate with a domain-service (because you no longer need to check the state of the domain client before issuing a new command) and secondly, it allows for offline and occasionally connected scenarios where the queue can be paused when network connectivity is broken and resumed when connectivity is restored. If the queue is made persistent (via isolated storage) then true off-line capability is then possible. Note that to be truly offline it must be possible to submit requests for data which either go to the server via RIA or are satisfied by some kind of local storage if offline – this is another area I would like to explore in the fullness of time. Imagine if you will, a domain service client proxy object…
5. In lieu of a Silverlight database the best we can do is wrap that functionality into isolated storage and XML files and hide the ugliness with a LINQ-to-XML facade… This at least will work on non-Microsoft client platforms (as opposed to COM interop solutions)
6. With the “XML database” in order we can then take a long hard look at a proxy object alluded to in point 4.
7. Returning to Prism philosophies of supporting dual WPF/Silverlight development paths to ease the creation of composite WPF, MVVM, occasionally connected applications.
So where is it? Okay the first draft has been uploaded to CodePlex and can be seen in all its glory here.
