Lokad CQRS does not use Windows Azure Table Storage

We've got really interesting question in Ask Lokad community today. It actually highlights an important architectural decision made in Lokad.CQRS

We're taking a look a the implementation of "Sample05 - Web + Worker", and wondering whether it is possible to use table storage rather than blob storage as the backing store for ViewReader/ViewWriter.

It looks like blob storage and file storage are the two provided implementations, but perhaps we're missing something.

It seems like it would it make sense to use TableStorage for many types of views (given Table Storage or the 100x cost factor).

Thoughts? Should we back off ViewReader/ViewWriter for now and go with CloudTable instead, or is there a vision behind ViewReader/ViewWriter that we should wait to unfold ?

Thanks Scott!

Lokad.CQRS explicitly does not support Table Storage, while focusing on Windows Azure Blob Storage instead. This was a conscious choice based on experience, extreme performance scenarios and just resulting complexity in the code. Table Storage brings more problems that benefits for the CQRS in the Cloud approach:

• Lokad.CQRS solutions built with TableStorage model will be less portable (between various cloud platforms and on-premises deployments).
• There is a strong theory behind this choice (Pat Helland's works, DDD thinking and their mapping to CQRS).
• It's possible to do logical batch inserts to Blobs as well (just depends on how you define partition boundaries and processing).
• Azure Blobs map directly to the CDN features, which makes them perfect candidate for CQRS Views and scaling.
• Table storage does not support MD5 hashing, while Blob Storage does.
• Even with Lokad.Cloud, you can't put more than 960 Kb into a row in Table Storage.
• There are also a few more caveats with the TableStorage, which Lokad R&D could probably explain better than I do.

Basically, I embedded into Lokad.CQRS some experience coming from Lokad.Cloud framework. The latter stresses Windows Azure in many ways (researchers tend to do this often) and provides invaluable source of information and feedback.

In short, Windows Azure Blob Storage with ViewReader and ViewWriter are the preferred option for CQRS view persistence (interfaces and classes will be refactored within the next 1-2 months). As for the command processing (write-side), there will probably be other approaches (since CQRS is inherently persistence-ignorant). Options will probably include:

• NHibernate for SQL Azure (a la lightweight CQRS in Cloud) - production tested and available right now as a separate module in Lokad.CQRS (plugs directly into the transaction scopes);
• Direct state persistence to Blob.
• Event Sourcing.

In essence, current release of Lokad.CQRS was mostly about the CQRS-opinionated Open Source Service Bus for Windows Azure (with some guidance and and helpers). Second release will focus on building actual CQRS solutions, based on our current experience.