Question

First, I apologize if this is not an appropriate venue to ask this question, but I wasn’t really sure where else to get input from.

I have created an early version of a .NET object persistence library. Its features are:

• A very simple interface for persistence of POCOs.
• The main thing: support for just about every conceivable storage medium. This would be everything from plain text files on the local filesystem, to embedded systems like SQLite, any standard SQL server (MySQL, postgres, Oracle, SQL Server, whatever), to various NoSQL databases (Mongo, Couch, Redis, whatever). Drivers could be written for nearly anything, so for instance you could fairly easily write a driver where the actual backing store could be a web-service.

When I first had this idea I was convinced it was totally awesome. I quickly created an initial prototype. Now, I’m at the ‘hard part’ where I am debating issues like connection pooling, thread safety, and debating whether to try to support IQueryable for LINQ, etc. And I’m taking a harder look at whether it is worthwhile to develop this library beyond my own requirements for it.

---

Here is a basic example of usage:

var to1 = new TestObject { id = "fignewton", number = 100, FruitType = FruitType.Apple };

ObjectStore db = new SQLiteObjectStore("d:/objstore.sqlite");
db.Write(to1);
var readback = db.Read<TestObject>("fignewton");

var readmultiple = db.ReadObjects<TestObject>(collectionOfKeys);

The querying interface that works right now looks like:

var appleQuery = new Query<TestObject>().Eq("FruitType", FruitType.Apple).Gt("number",50);
var results = db.Find<TestObject>(appleQuery); 

I am also working on an alternative query interface that lets you just pass in something very like a SQL WHERE clause. And obviously, in the NET world it would be great to support IQueryable / expression trees.

Because the library supports many storage mediums with disparate capabilities, it uses attributes to help the system make the best use of each driver.

[TableName("AttributeTest")]
[CompositeIndex("AutoProperty","CreatedOn")]
public class ComplexTypesObject
{
    [Id]
    public string id;

    [QueryableIndexed]
    public FruitType FruitType;

    public SimpleTypesObject EmbeddedObject;
    public string[] Array;
    public int AutoProperty { get; set; }
    public DateTime CreatedOn = DateTime.Now;
}

All of the attributes are optional, and are basically all about performance. In a simple case you don’t need any of them.

In a SQL environment, the system will by default take care of creating tables and indexes for you, though there is a DbaSafe option that will prevent the system from executing DDLs.

It is also fun to be able to migrate your data from, say, a SQL engine to MongoDB in one line of code. Or to a zip file. And back again.

OK, The Question:

The root question is “Is this useful?” Is it worth taking the time to really polish, make thread-safe or connection pooled, write a better query interface, and upload somewhere?

• Is there another library already out there that already does something like this, NAMELY, providing a single interface that works across multiple data sources (beyond just different varieties of SQL)?
• Is it solving a problem that needs to be solved, or has someone else already solved it better?
• If I proceed, how do you go about trying to make your project visible?

Obviously this isn’t a replacement for ORMs (and it can co-exist with ORMs, and coexist with your traditional SQL server). I guess its main use cases are for simple persistence where an ORM is overkill, or for NoSQL type scenarios and where a document-store type interface is preferable.

Answer 1

My advice: Write it for your own requirements and then open-source it. You’ll soon find out if there’s a market for it. And, as a bonus, you’ll find that other people will tell you which bits need polishing; there’s a very high chance they’ll polish it for you.