This project has moved and is read-only. For the latest updates, please go here.

Sterling compared to RavenDB

Dec 29, 2010 at 1:26 PM

Sterling seems to be developed focusing on Windows Phone 7, but as it's also for Silverlight, I assume it would make a possible solution for storage for a WPF desktop app also? This is an app I am planning to convert to Silverlight. It now uses RavenDB, but because of licensing issues, I would consider Sterling.

The power of RavenDB to me, is that you give it your object, and it is persisted, with all child objects. You have to take care to work in a neat DDD approach, i.e. your aggregate root is what Raven calls your Document.

Does Sterling do the same? Can I give it an object with children (where each child could have child objects again), and would it save everything?

What other differences/similarities would you point me to?

Dec 29, 2010 at 1:35 PM

A few things. First, yes, the goal of Sterling is to give it an object and persist the complex object graph. There is an outstanding defect I am working on to accomplish this, as right now it won't traverse the full graph - looking to get that addressed before the New Year, and then yes, you will be able to give any complex object graph and Sterling will serialize the entire tree for any value type it understands. For those it doesn't, you can override and provide your own serializer.

RavenDB and Sterling have different goals. RavenDB is far more comprehensive and has much more support - it is not nearly as lightweight as Sterling. I would not even dream of trying to take Sterling to the level of RavenDB, it's just a different approach. Once Sterling starts to get more complicated features, I start to say, there's more mature/robust frameworks there. Sterling tries to keep it lightweight and simple - it's not a document database and it's not a relational database. It's a facility for easily serializing objects and providing fast quering of properties you define. Unlike RavenDB, for example, that can create indexes on the fly, with Sterling you have two options: an optimized startegy, where you supply the most used attributes up front in the keys and indices, and what I'll call the "slow" strategy, that allows you to query any property on the object but requires each object is deserialized to inspect the properties which can be a significant performance hit if you are dealing with thousands of entities.

I am going to be working on more comprehensive documentation and as a part of that will likely include a piece that compares Sterling to other approaches to help people understand the trade-offs. The license is a very open license however so you should be able to take it and run with it however you like in your project if it is falling short. I am committed to having a very solid and well-tested, feature rich version 1.0 RTM early 2011 (January or February time frame). We also have many people using it already in their applications, so I'm trying to collect case studies and testimonials so you can read about the experiences others are having with it.


Dec 29, 2010 at 1:55 PM

Thanks for your reply Jeremy. RavenDB is indeed overkill for my desktop application, but it's the ease of use I'm looking for: give it your object and let it handle the persisting. So it seems Sterling offers the same. I'll give it a test-drive, in particular to see how bad the performance hit you mention will be.

Dec 29, 2010 at 2:10 PM

Sure! And the performance hit is really only when you are dealing with properties that aren't part of a key/index. The latest blog post I made goes into a bit more detail of the inner workings if that helps:

The main difference on the desktop will be the queries can return IQueryable directly, so you don't have to cast to a list before performing advanced LINQ to Object operations.