6

首先，如果这不是提出这个问题的合适场所，我深表歉意，但我真的不确定还能从哪里获得意见。

我创建了一个早期版本的 .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 类型场景以及文档存储类型接口更可取的地方。

4

4 回答 4

4

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

于 2010-06-30T01:12:01.070 回答
2

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

于 2010-06-30T01:24:59.990 回答
1

对于它的价值，我认为这是一个好主意。

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

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

于 2010-06-30T02:04:29.430 回答
1

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

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

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

于 2010-06-30T02:16:18.320 回答