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

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 文件。然后又回来了。

好的，问题：

根本问题是“这有用吗？”是否值得花时间真正打磨，使线程安全或连接池化，编写更好的查询接口，然后上传到某个地方？

• 是否有另一个库已经在做类似的事情，即提供跨多个数据源工作的单一界面（不仅仅是不同类型的 SQL）？
• 是解决一个需要解决的问题，还是其他人已经更好地解决了它？
• 如果我继续，您将如何努力让您的项目可见？

显然，这并不是 ORM 的替代品（它可以与 ORM 共存，并与传统 SQL 服务器共存）。我猜它的主要用例是用于简单的持久性，其中 ORM 太过分了，或者用于 NoSQL 类型场景，并且文档存储类型接口更可取。

Answer 1

我的建议：根据自己的需求编写，然后开源。你很快就会发现它是否有市场。而且，作为奖励，你会发现其他人会告诉你哪些部分需要改进；他们很有可能会为您打磨它。

Answer 2

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

Answer 3

就其价值而言，我认为这是一个好主意。

但更重要的是，您选择的项目（在我看来）无疑会提高您的代码构建和设计能力。通常很难找到既能增加价值又能提高你的技能的项目。

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

Answer 4

虽然我认为这个想法很有趣并且可能有用，但我不确定它可能具有什么长期价值。鉴于 EF v4 最近取得了相当大的进步，包括仅代码、真正的 POCO 支持等，使用 EF 实现您所说的实际上并不困难。如今，我是 Code-Only 的忠实拥护者，因为它简单、功能强大，最重要的是，它可以在编译时进行检查。

支持任何类型的数据存储的想法很有趣，并且值得研究。但是，我认为，如果您为 EF v4 实现了商店提供程序，而不是尝试重新发明微软现在花费多年的轮子，那么它可能会更有用，并且可以覆盖更广泛的受众。小项目往往会增长......并且池化、线程安全、LINQ/IQueryable 支持等事情会随着时间的推移而变得更加重要......一点一点地。

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