我对对象持久性库的想法有用吗？

首先,如果这不是一个提出这个问题的合适场所,我很抱歉,但我不确定从哪里获得输入.

我已经创建了.NET对象持久性库的早期版本.它的特点是:

一个非常简单的POCO持久性接口.

主要的是:支持几乎所有可以想象的存储介质.这将是从本地文件系统上的纯文本文件到SQLite等嵌入式系统,任何标准SQL服务器(MySQL,postgres,Oracle,SQL Server等)到各种NoSQL数据库(Mongo,Couch,Redis等)的一切.驱动程序几乎可以编写任何东西,因此,例如,您可以非常轻松地编写驱动程序,其中实际的后备存储可以是Web服务.

当我第一次有这个想法时,我确信它非常棒.我很快创建了一个初始原型.现在,我正在讨论连接池,线程安全以及是否尝试支持LINQ等IQueryable等问题的"困难部分".我正在更加努力地看看是否值得开发这个库超出了我自己的要求.

这是一个基本的使用示例:

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("fignewton");

var readmultiple = db.ReadObjects(collectionOfKeys);

现在可以使用的查询界面如下所示:

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

我还在研究另一种查询接口,它允许您传递非常类似于SQL WHERE子句的内容.很明显,在.NET世界中支持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选项可以阻止系统执行DDL.

能够在一行代码中将数据从SQL引擎迁移到MongoDB也很有趣.或者是一个zip文件.又回来了.

好的,问题:

根本问题是"这有用吗？" 是否值得花时间进行真正的润色,使线程安全或连接池化,编写更好的查询界面,并上传到某个地方？

是否已经有另外一个已经做过这样的事情的图书馆,NAMELY,提供一个可以跨多个数据源工作的单一界面(不仅仅是不同种类的SQL)？

它是在解决需要解决的问题,还是其他人已经更好地解决了这个问题？

如果我继续,你如何尝试让你的项目可见？

显然,这不是ORM的替代品(它可以与ORM共存,并与您的传统SQL服务器共存).我猜它的主要用例是简单的持久性,其中ORM是过度的,或者对于NoSQL类型的场景,以及文档存储类型接口更可取.