c# - ORM/永続層アドバイス

Question

私は新しいプロジェクトを開始しており、非常に優れた ORM または非 SQL ベースの永続化レイヤーを探しています。
このプロジェクトでは、妥当な速度で、そして最も重要なこととして単純なクエリでデータをクエリおよび保存できる限り、データがどのように永続化されるかは気にしません。
同時実行性はシームレスに処理する必要があり (フロントエンドは別の層にあり、複数の同時ユーザーが存在しますが、必ずしも同じデータで作業しているわけではありません)、データ層に集中する必要が少なくなります (簡単なクエリ、自動遅延)。ローディングなど）より良い。
また、LINQ をサポートするツールや、直感的で厳密に型指定されたクエリをサポートするツールが大きなボーナスを得られるように、文字列ベースのクエリをいじる必要は絶対に避けたいと考えています。
最後に、POCO オブジェクトを操作することは、私が本当にやりたいことの 1 つです
。これは、私が評価した製品のリストと、それらが適合しない理由です。これらの使用に関するアドバイスは表示されません。

NHibernate: クレイジーな xml のもの、セットアップが多すぎる、メンテナンスの複雑さとモデル変更のコストが高い、セッションファクトリが面倒で、私のニーズにうまく適合しない
Castle ActiveRecord: NHibernate ベースで、ドキュメントがほとんどなく、NHibernate に関連する問題がいくつか残っています。さらに、適切なモデルを取得するには非常に多くの属性が必要になるため、スキーマを手動で作成する方が適切であり、リレーションの処理方法が残念です。
Linq To SQL: POCO オブジェクトが欠落しており、MS によると、残業時間はあまり改善されません (EF は彼らがコミットしているものです)
Entity Framweork: v4 では POCO オブジェクトを使用できますが、それでもかなりハックであり、設定に手作業が多すぎます。その上、v4 は単なるベータ版です
LLBLGen Pro: 特に SelfServicing アダプターの場合は良好ですが、POCO はそうではありません。また、LINQ プロバイダーはまだ完全ではありません。最後に、LINQ を介してオブジェクトのグループを削除することはできません。その結果、API が混在することになり (そのうちの 1 つは直感的とはほど遠いものです)、私はそれが好きではありません。
XPO: POCO ではなく、直感的で非常に遅い同時実行の問題
SubSonic SimpleRepository: 数分間、私は夢を見ていると思いました。物事がどのように関係を処理しなかったかを理解したので、ディームは終わりました

私は MongoDB と CouchDB も調べましたが、これらの場合、関連オブジェクトのキャッチは、物事を正しく行う前にあまりにも多くのテストを必要とするように見えました。さらに、厳密に型指定されたクエリを提供するものはありません。

ご提案いただきありがとうございます。

score 7 · Accepted Answer

LLBLGen ライセンスを購入する余裕がある場合は、購入してください。

LINQ クエリ構文は、使えば使うほど好きではありません (ただし、拡張メソッドや式ツリーなど、それに関連する言語機能は大好きです)。

私は他のみんなと同じように最初は好きでしたが、その XYZ LINQ プロバイダーの [[ where employee.Name.StartsWith("John Smit") ]] が SQL ステートメントで行われるのか、LINQ to Objects で行われるのか (SQL がすべてを返した後) は不明でした。結果)、および [[ user.Roles.Contains(role) ]] がまったく機能するかどうかは、大きな一歩遅れています。

LLBLGen を使用すると、アイテムをロードせずにすべてのアイテムを簡単に削除できます。

MyEntityCollection.DeleteAll( new MyEntity {Condition = value} );

これはかなりシンプルで気に入っています。遅延読み込みを取得し、デフォルトで、および/または Prefetch API を使用してクエリごとに熱心な/深い読み込みを設定します。任意のフィルター/ソート/ロードを無限レベルで動的に (そして簡単に) 構成および構築できます。それは非常にうれしいです。

LLBLGen には 2 つの問題しかありません。まず、Microsoft の代替製品が誇大宣伝されていることを考えると、すべての企業が支払いたがらない価格です。次に、命名規則は RDBMS 理論では標準ですが、"where" または "filter" の代わりに PredicateFactory 、ディープローディングの代わりに Prefetch 、さらには orderby の代わりに SortExpression など、最初にそれを扱う開発者にとっては少し怖いものです。しかし、彼らが与える力と安らぎを考えると、すぐに彼らを愛することを学びます。LLBLGen 3.0 での POCO サポートについての話があります。詳しくないのでなんとも言えません。

LLBLGen を使用している会社で働いていないことを考えると、会社が LINQ to SQL を使用する主な理由は、多くのプロジェクトで大きな失敗がなく「証明されている」からです (EF 1 とは異なり、LINQ to SQL の LINQ 機能さえ欠けていて、非常に優れています)。パフォーマンスが悪く、高度なマッピングではかなり制限される可能性があります-これが最適なはずです!)。私はこの会社で両方を使用しましたが、両方が嫌いでした。新しいプロジェクトの決定は引き続き LINQ to SQL であり、その限界を克服するためにできる限りのことを行いました。この Web サイト StackOverflow 自体がその上で実行されます!!! これを回避して SEMI-POCO を実行できます (関連付けに関しては、L2S 関連の型を使用する必要があります)。

また、家でいくつかの小さなプロジェクトを行います。私は LLBLGen ライセンスを持っていないので、NHibernate を学び、それを Fluent NHibernate および LINQ To NHibernate と一緒に使用することにしました。これを通じて、NHibernate が非常に強力であることを学びました。DB スキーマを自動的に更新するなど、いくつかの機能によって作業方法が変わりました (D を使用するときはほとんど触れませんでした)。LINQ プロバイダー (NHibernate Contrib プロジェクト内) がかなり不足している場合がありますが、NHibernate 自体の未リリースのソースコードには、より優れた LINQ プロバイダーが含まれています (まだ試していません)。NHibernate の「セッション」には、L2S の DataContext または EF の ObjectContext に関連するものと同様の Web 開発を行っている場合に問題があります (セルフトラッキングエンティティのおかげで、LLBLGen は問題に悩まされません)。

私が NHibernate で抱えていた最大の問題は、情報を見つける能力でした。特定の方法でまとめる必要のある部分が多すぎて、ガイダンスがあまりない場合は、マッピングとクエリの両方に関する高度な情報を含めることができます。そうでなければ、たまたま NHibernate プロジェクトのソースコードのコミッターである友人 (Tuna Toksoz 、Twitter の @tehlike) がいたら、私は本当に深刻な問題を抱えていたでしょう。

私が学んだ教訓は次のとおりでした: ちょうど機能するもので少し基本的な使用が必要な場合は、Linq To Sql または SubSonic を使用し、中間のものが必要であり、実稼働環境で BETA .NET バージョン (golive が存在する場合) を使用する余裕がある場合は、Entity Framework 4.0 を使用します、非常に強力なものが必要で、ハードな学習プロセスを実行する余裕がある場合は、NHibernate を使用してください。さらに、LLBLGen を使用する余裕がある場合は、それを使用してください。

score 6 · Accepted Answer

DataObjects.Netを見てください:

利点:

単純なクラスと属性を使用してビジネスモデルを設計しやすい
データベーススキーマは実行時に自動的に生成されるため、データの保持方法を気にする必要はありません
自動遅延読み込み、透過的永続性など...
本当に良いLINQ実装
ハイパフォーマンス

短所:

ポコではない

score 4 · Accepted Answer

細心の注意を払いながら、NHibernate の弱点に関するあなたの評価には絶対に反対する傾向があります。

XML マッピングは非常に単純で直感的に作成できると思います。NHibernate.dll への参照を追加し、SessionFactory を作成するのも簡単です。メンテナンスと変更管理が大幅に簡素化されます。セッションファクトリとセッションは、非常に理解しやすく、扱いやすいものです。

全体として、あなたは感情的であり、評価に関して合理的ではないと思います。

score 3 · Accepted Answer

db4oなどのオブジェクト指向データベースの使用について考えたことはありますか。使用したことはありませんが、発見したときは非常に興味深いものでした。

LINQ クエリをサポートし、POCO を使用します。私の理解が正しければ、データは単純にファイルに格納されます (データベースのインストールは必要ありません)。

いくつかのリンク:チュートリアル、フォーラムの投稿

score 2 · Accepted Answer

Write your own ORM

It might sound crazy but you can write your own ORM. Sometime back in a project the client did not want to use 3rd party tools or libraries and for that reason, we ended up writing our own ORM which served specific objectives for us. You can decorate your objects' classes and properties with Attributes to map them with Database tables and fields. Have base class for all the business objects and do database operations on the objects using reflection.

This way you can build your own tiny ORM to suit the particular objectives you want.For your reference It may somewhat look like this.

[TableMapping("Users", "User", "Users")]
public class User : EntityBase
{
    #region Constructor(s)
    public User()
    {
    }
    #endregion

    #region Properties

    #region Default Properties - Direct Field Mapping using DataFieldMappingAttribute

    private System.Int32 _UserId;

    private System.String _UserName;

    [DataFieldMapping("UserID")]
    [DataObjectFieldAttribute(true, true, false)]
    [NotNullOrEmpty(Message = "UserID Is Required.")]
    public override int Id
    {
        get
        {
            return _UserId;
        }
        set
        {
            _UserId = value;
        }
    }

    [DataFieldMapping("UserName")]
    [NotNullOrEmpty(Message = "Username Is Required.")]
    public string UserName
    {
        get
        {
            return _UserName;
        }
        set
        {
            _UserName = value;
        }
    }

    #endregion

    #region One-To-Many Mappings
    #endregion

    #region Derived Properties
    #endregion

    #endregion
}

score 2 · Accepted Answer

LLBLGen.

あなたのすべてのボックスをチェックする何かを見つけるつもりだと思うなら、あなたは長い間待つことができます.

score 2 · Accepted Answer

LLBLGenPro、NHibernate、およびいくつかのオブジェクトデータベースを使用しました。

私の最初の推奨事項は、マッピングを処理するために FluentNhibernate を使用する NHibernate です。

NHibernate の使用に関連する問題の 90% は、XML マッピングに直接関係していることがわかりました。FluentNhibernate に切り替えたところ、痛みがなくなりました。

残りの 10% の難しさは単に無知です。私はそれを理解していませんでした。それは Hibernate のせいではありません。

LLBLGenPro: Linq のサポートが今どうなっているのかはわかりませんが、Linq がサポートされる前はクエリを書くのが PITA でした。私はドキュメントを読んで理解しましたが、同僚はそうではなく、プリフェッチパスなどの複雑さについて際限なく不満を漏らしていました。さらに、あなたが言ったように-POCOではありません。コストを加えると、価値があるよりもはるかに面倒だと思います.

クライアントサーバーアーキテクチャでない場合は、db40 をお勧めします。私はそれを小さなプライベートプロジェクトで使用し、気に入りました。使いやすい。優れた小さなオブジェクトデータベース。

score 1 · Accepted Answer

TelerikORMをご覧ください。私はこれを本番環境で使用していませんが、数年前に非常にうまく機能したPOETと呼ばれるJava ORM\ODBに基づいていました。アセンブリ拡張機能を使用しているため、上記で拒否した一部の製品よりもはるかに透過的なエクスペリエンスを提供します。

Versantによる純粋なODBFastObjectsに関しては、おそらく一見の価値があります。

頑張ってください-あなたが何をすることに決めたかを私たちに知らせてください。

score 1 · Accepted Answer

EntitySpacesを見てください。私自身の個人的な経験からはお勧めできませんが、私の同僚の 1 人 (ソフトに興味のない人) には効果的です。

score 1 · Accepted Answer

私にとって、その答えは LLBLGen Pro であることが判明しました。その機能に加えて、プロジェクトが機能するように支援することを気にかけている専任のサポートチームを獲得できます。バグを発見した場合、ほとんどの場合、数時間または数日で修正されます。リリースを (数か月?) 待ったり、自分でバグを修正したりするのではなく、作業を続けることができるため、これを最小限に抑えることはできません。

score 1 · Accepted Answer

1

ここでAspectizeを見てみましょう

于 2009-10-31T20:18:40.023 に答える

c# - ORM/永続層 アドバイス

11 に答える 11

Related

Reference

c# - ORM/永続層アドバイス