Question

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

我已经创建了.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<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);

我还在开发一个替代查询接口，它允许您传递非常类似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类型的场景，以及文档存储类型接口更可取。

Answer 1

我的建议：根据自己的要求编写，然后开源。你很快就会发现它是否有市场。并且，作为奖励，你会发现其他人会告诉你哪些位需要抛光;他们很有可能为你擦亮它。

Answer 2

本，我觉得很棒。至少将它发布到CodePlex并与世界其他地方分享。我很确定那里有开发人员可以使用对象持久性框架（或帮助完善它）。

Answer 3

我认为这是一个好主意。

但更重要的是，你选择了一个项目（在我看来），无疑会改进你的代码构建和设计印章。通常很难找到能够在提高技能的同时增加价值的项目。

至少完成它的初始要求，然后开源。之后的任何事情都是奖金！

Answer 4

虽然我认为这个想法很吸引人，并且可能有用，但我不确定它可能具有的长期价值。鉴于最近EF v4取得了相当大的进步，包括Code-Only，真正的POCO支持等等，实现你所谈论的内容对于EF来说实际上并不困难。我现在是Code-Only的忠实信徒，因为它简单，强大，最重要的是，编译时检查。

支持任何类型的数据存储的想法是有趣的，值得研究的东西。但是，如果你为EF v4实现商店提供商，而不是试图重新发明微软现在花费数年时间的轮子，我认为这可能会更有用，并且可以覆盖更广泛的受众。小项目往往不会增长......而诸如池，线程安全，LINQ / IQueryable支持等等变得越来越重要......随着时间的推移逐渐变得越来越重要。

通过为SqLite，MongoDB，Xml文件或平面文件等开发EF数据存储提供程序，您可以添加现有的，熟悉的，可访问的框架的功能，而无需人们学习额外的框架。

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

好的，问题：

4 个答案: