6

まず、これがこの質問をするのに適切な場所ではないことをお詫びしますが、他にどこから情報を得ることができるかはよくわかりませんでした。

.NETオブジェクト永続化ライブラリの初期バージョンを作成しました。その機能は次のとおりです。

  • POCOの永続性のための非常にシンプルなインターフェース。
  • 主なもの：考えられるほぼすべてのストレージメディアのサポート。これは、ローカルファイルシステム上のプレーンテキストファイルから、SQLiteなどの組み込みシステム、標準SQLサーバー（MySQL、postgres、Oracle、SQL Serverなど）、さまざまなNoSQLデータベース（Mongo、Couch、Redisなど）まで、あらゆるものになります。ドライバーはほぼすべての目的で作成できるため、たとえば、実際のバッキングストアがWebサービスである場合にドライバーを簡単に作成できます。

私が最初にこのアイデアを思いついたとき、私はそれが完全に素晴らしいと確信していました。私はすぐに最初のプロトタイプを作成しました。現在、接続プール、スレッドセーフ、IQueryable for 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);

また、SQLWHERE句のようなものを渡すことができる代替クエリインターフェイスにも取り組んでいます。そして明らかに、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環境では、システムがデフォルトでテーブルとインデックスの作成を処理しますが、システムがDDLを実行できないようにするDbaSafeオプションがあります。

たとえば、SQLエンジンからMongoDBに1行のコードでデータを移行できるのも楽しいことです。またはzipファイルに。そしてまた戻って。

OK、質問：

根本的な質問は「これは役に立ちますか？」です。時間をかけて本当に磨き、スレッドセーフまたは接続をプールし、より優れたクエリインターフェイスを作成し、どこかにアップロードする価値はありますか？

  • すでにこのようなことを行っている別のライブラリ、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

このアイデアは興味深く、役立つかもしれないと思いますが、それがどのような長期的な価値を持っているのかはわかりません。最近のEFv4の大幅な進歩を考えると、コードのみ、真のPOCOサポートなど、あなたが話していることを達成することは、実際にはEFではそれほど難しくありません。私はコードを真に信じています-シンプルで強力、そして何よりもコンパイル時がチェックされているので、最近だけです。

あらゆる種類のデータストアをサポートするというアイデアは興味深いものであり、検討する価値があります。ただし、Microsoftが長年費やしてきた車輪の再発明を試みるよりも、EF v4のストアプロバイダーを実装した方が、より便利で、かなり幅広いユーザーにリーチできると思います。小さなプロジェクトは成長することがほとんどです...そして、プーリング、スレッドセーフ、LINQ / IQueryableサポートなどのようなものは、時間の経過とともに少しずつ重要になります。

SqLite、MongoDB、Xmlファイル、フラットファイルなどのEFデータストアプロバイダーを開発することで、既存の使い慣れたアクセス可能なフレームワークの機能を追加できます。追加のフレームワークを学ぶ必要はありません。

于 2010-06-30T02:16:18.320 に答える