Полезна моя идея для объектной библиотеки персистентности?

Во-первых, я приношу извинения, если это не соответствующее место проведения для задавания этого вопроса, но я не был действительно уверен, откуда еще быть введенным.

Я создал раннюю версию библиотеки персистентности объекта.NET. Его функции:

• Очень простой интерфейс для персистентности POCOs.
• Главное: поддержка примерно каждого мыслимого носителя. Это было бы всем из файлов простого текста в локальной файловой системе, к встроенным системам как SQLite, любой стандартный SQL-сервер (MySQL, пост-ГРЭС, Oracle, SQL Server, безотносительно), к различным базам данных NoSQL (монго, Диван, Redis, безотносительно). Драйверы могли быть записаны почти для чего-либо, так например, Вы могли довольно легко записать драйвер, где фактическое запоминающее устройство могло быть веб-сервисом.

Когда у меня сначала была эта идея, я был убежден, что это было полностью потрясающим. Я быстро создал начальный прототип. Теперь, я в 'твердой части', где я обсуждаю проблемы как организация пула подключений, потокобезопасность, и дебатирую, попытаться ли поддерживать IQueryable для LINQ, и т.д. И я бросаю более трудный взгляд на то, стоит ли разработать эту библиотеку вне моих собственных требований для него.

Вот основной пример использования:

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);

Интерфейс запросов, который работает правильно теперь, похож:

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

Я также работаю над альтернативным интерфейсом запросов, который позволяет Вам просто передать в чем-то в точности как оператор Where SQL. И очевидно, в СЕТЕВОМ мире было бы замечательно поддерживать IQueryable / деревья выражений.

Поскольку библиотека поддерживает много носителей с разрозненными возможностями, она использует атрибуты, чтобы помочь системе лучше всего использовать каждый драйвер.

[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;
}

Все атрибуты являются дополнительными, и являются в основном всеми о производительности. В простом случае Вам не нужен ни один из них.

В среде SQL система будет по умолчанию заботиться о составлении таблиц и индексов для Вас, хотя существует опция DbaSafe, которая будет препятствовать тому, чтобы система выполнила DDLs.

Это - также забава смочь переместить Ваши данные от, скажем, механизма SQL до MongoDB в одной строке кода. Или к zip-файлу. И назад снова.

Хорошо, вопрос:

Основной вопрос, "Действительно ли это полезно?" Действительно ли это стоит занять время для реальной полировки, сделайте ориентированными на многопотоковое исполнение или соединение объединенный, запишите лучший интерфейс запросов и загрузите где-нибудь?

• Уже есть ли другая библиотека там, которая уже делает что-то вроде этого, А ИМЕННО, обеспечивая единственный интерфейс, который работает через несколько источников данных (вне просто различных вариантов SQL)?
• Это решает проблему, которая должна быть решена, или кто-то еще уже решил его лучше?
• Если я продолжаю двигаться, как Вы идете о попытке сделать Ваш проект видимым?

Очевидно, это не замена для ORMs (и он может сосуществовать с ORMs и сосуществовать с Вашим традиционным SQL-сервером). Я предполагаю, что его основные варианты использования для простой персистентности, где ORM является излишеством, или для сценариев типа NoSQL и где интерфейс типа хранилища документа предпочтителен.