Silverlight and Object Databases

Stop Press: Most of the issues below have now been resolved with the release of Silverlight-3 & RIA Services. See the following post for more details - A Domain-Driven, DB4O Silverlight-3 RIA

I recently decided to write myself a quick Silverlight application for a bit of fun. I wanted an app that could grab stock quotes, do a calculation of my current losses and maybe have some nice blue-gel buttons and what-not. A few evenings of light coding pleasure and good break from all that architectural stuff.  Naturally it did not quite work out that way.

I got a wireframe working pretty quickly but that was not good enough. I wanted to serialize my data so I could start to get some fancy Silverlight graphs with bouncy bars. So I found myself grabbing multiple quotes and using the data to instantiate domain objects in the Silverlight client. Now what? I needed to serialize these instances on the web server. So how do I do that?

I had two options

1. Use isolated storage on the client then use Mesh to synch the data. The only problem with this approach is that the last sentence is the total extent of my knowledge. I want a slope not a cliff face.

2. Use a good old database on the server, why not, and since I am about it lets make that an object database so we don't have to concern ourselves with all that old-fashioned NHibernate, ORM tosh (ah - how quickly I become intolerant).

I chose option #2. And right there it started to get annoying. What I really wanted to do was just use my ODB in the Silverlight client code as if I was coding normally. But of course the Silverlight sandbox had lots to say about that.

To get around this you must write a WCF service layer. Call this an API and you will feel much better because that makes it sound quite cool and computery. You need this comfort blanket because you are about to climb into a time machine a go back 10 years to when you were a script kiddie banging out ASP code.

This WCF 'API' service is going to be the only means you have to serialize data and transmit it between the Silverlight client and the web server. The [DataContract] will require [DataMember] methods to cover every possible action, just like writing all those CRUD sprocs for a relational DB. Of course you could break this jumbled, untestable mess into smaller WCF contracts but that is just more fantasy to cover the poor design, like putting prefixes on your sproc names so they group together to simulate a business layer.

No, the real solution is to do away with the WCF data-layer before you even start. Now don't get me wrong, WCF is fine and very useful but I think it is an abuse to use it a domain serialization interface. We just got rid of RDB DALs so why create another DAL for SaaS?

What is needed is grown up client / server relationship. That would be much better. Then, instead of writing a sprawling WCF thunking layer replete with DTO auto-mappers and all that junk paraphanalia, you get a nice generic client-centric solution with code like this:

myODB.Store(myObject) ;

myODB.Commit();

This focuses coding attention away from the boilerplate WCF data transformation layer and back on to the business useful world of the Domain - where it belongs.

By the way, you can use dotnet assemblies in a Silverlight project. It needs a few quick (but legitimate) 'fixes' to the IL to get them past the Visual Studio fascist guards. I am finishing off a tool that automates the IL work for you makes it nice and easy to convert dotnet assemblies into Silverlight reference-ready assemblies. I will post it here soon.

Stop Press: You can now download the IL Tool mentioned above. See the following blog post for more details - Convert dotnet assemblies to Silverlight