Defining a reference architecture for Silverlight LOBs

Update October 2010: I’ve started a new in-depth series on my current Silverlight 4 Reference Architecture.

Recently I've been catching up on Silverlight by reading Pro Silverlight 2 in C# and the many blogs and articles on Silverlight 3 and I'm seriously impressed. The reason for this sudden interest is the fact that I'm considering Silverlight as an alternative to ASP.NET for building line-of-business applications. Silverlight 2 was promising, but lacked some important features that are required in full-screen Silverlight apps. However, Silverlight 3 has introduced some major improvements that convinced me that it is finally ready for replacing ASP.NET for controlled environments.

Since I'm quite fond of Martin Fowler's approach to Evolutionairy Design, I'd like to have at least a rough idea of where I'm going to in terms of architecture and technology support. Consequently, I've been thinking hard to come up with a list of features and ideas I'd like to consider in a SL architecture. The list is not complete, so I’ll adapt it regularly. But since I assume more people are trying to cross that same bridge, I though sharing my wish list could be useful.

General

• Simple Design, Test-Driven Development and Refactoring are the foundation of all design and development efforts.
• I will explicitly consider every recommendation from the RIA Pocket Guide and make sure they are either included in the design or made part of the product backlog.
• I'm seriously considering to use MOQ instead of Rhino Mocks. I've been using Rhino for over two years, but Ayende hasn't reported much development anymore and its Silverlight support is only alpha. MOQ has official Silverlight support and appears to be very active.
• I'll start with Visual Studio 2008 SP1, but will switch to Visual Studio 2010 Beta 2 when it arrives and has support for RIA Services.

The Application Server

• RIA Services to expose DTOs to the client. I have thought long and hard about how to fit RIA Services in a system, but I refuse to directly expose the domain model and pollute it with explicit choices about how far RIA should serialize a my domain entities. Therefore, I will expose DTOs only, even though I loose the automatic propagation of validation logic to the client.
• A Domain Model roughly designed according to DDD principles where cross-aggregate logic will be covered by Domain Services.
• Obviously I'll use NHibernate accompanied by LINQ and Fluent NHibernate (download them from here if you want a set of compatible builds).
• I'll still use the Repository pattern to hide any LINQ-to-NHibernate limitations. They will be exposed through an NHibernateObjectContext that serves as the unit-of-work and essentially wraps the ISession
• I'm considering to introduce Domain Events to keep any infrastructural logic from poluting the domain model. However, I'm not sure how worthwhile this purist approach will be.
• I've spend too much time hand-coding this translators in earlier projects, so I'm open to try out AutoMapper for this.
• As usual, I'll use Enterprise Library 4.1 on the backend for Policy Injection, Exception Handling, Validation and Logging. I'm not sure when version 5.0 will arrive, but I like its feature set. If it arrives in time, I will consider migrating (the 3.0 -> 4.1 migration was trivial).

The Silverlight client

• The use of Regions and Views such as the Composite Application Guidance (CAG) is providing, but without the concept of modules. The Web Client Software Factory had a similar concept, but I never found real use for them anyway.
• An Event Aggregator to allow communication between views and other components without them needing a direct reference to eachother. I'm not yet sure which one I'll use. CAG has a nice one, but Jeremy's version might be interesting as well.
• Dependency Injection through Unity for Silverlight.
• I wish there was a Policy Injection framework for Silverlight as well...
• RIA Services also adds a very nice mechanism for sharing code between the server and the Silverlight client, but I'm not sure yet how I'll use it. I think this is something that will become clear during development.
• The RIA DomainContext will be accessed through an interface so that the ViewModel classes can be unit tested properly without any dependency on RIA.
• INotifyPropertyChanged using lambda expressions instead of literal property names
• Model-View-ViewModel (essentially Presentation Model with INotifyPropertyChanged and INotifyCollectionChanged support)
• Some mechanism for hooking Silverlight controls to ICommand objects. I'm not sure yet whether I like the CAG implementation, so I may have to find an alternative.
• Silverlight Toolkit and Telerik's RadControls for Silverlight
• Deep linking with SL3's Navigation Framework