ORM for.NETを評価するための基準は何ですか？[閉まっている]

ORMの評価を検討しています。

私が使ってきた亜音速、LINQのツーSQLやEntity Frameworkのを。私は、ジュニアからシニアまでの開発者のチームを持っています。

ORM for.NETを評価するための基準は何ですか？

それはロードされた質問です。
さまざまな哲学で主題に近づいている非常に優れたORMがたくさんあります。
完璧なものはなく、黄金の道から外れるとすぐに（そして、時にはそれに固執したとしても）すべてが複雑になる傾向があります。

ORMを選択する際に自問すべきこと：

1. あなたにとって何をする必要がありますか？
   アプリケーションの要件のセットがすでにある場合は、仮想の「最良」ではなく、これらによく一致するORMを選択する必要があります。

2. データは共有されていますか、それともローカルですか？
   ORMの毛並みの多くは、複数のユーザーが同じデータのバージョンを保持している場合に、データベースのデータの同時性と変更を処理する方法によって発生します。
   データストアがシングルユーザー向けである場合、ほとんどのORMは適切に機能します。ただし、マルチユーザーシナリオでいくつかの難しい質問を自問してください。ロックはどのように処理されますか？オブジェクトを削除するとどうなりますか？他の関連オブジェクトにどのように影響しますか？ORMはバックエンドの金属の近くで機能していますか、それとも大量のデータをキャッシュしていますか（古くなっているリスクを犠牲にしてパフォーマンスを改善しています）。

3. ORMはアプリケーションのタイプに適していますか？ 特定のORMは、サービスで使用されている場合やWebアプリ内にある場合、作業が困難な場合があります（多くのパフォーマンスオーバーヘッド、コーディングが困難です）。それどころか、デスクトップアプリに最適かもしれません。

4. データベース固有の拡張機能を放棄する必要がありますか？
   ORMは、SQLの最小公分母セットを使用して、多くの異なるデータベースバックエンドで動作することを保証する傾向があります。
   すべてのORMは、使用可能な機能について妥協します（単一のバックエンドを明確に対象とする場合を除く）が、選択したバックエンドで利用可能な特定の拡張機能を活用するために追加の動作を実装できるものもあります。
   典型的なdb固有の拡張機能は、たとえば全文検索機能です。ORMが必要な場合にこれらの機能にアクセスする方法を提供していることを確認してください。

5. ORMはデータモデルの変更をどのように管理しますか？
   特定のメジャー内でDBを自動的に更新できるものもあれば、何もしないため自分で汚い作業をしなければならないものもあります。その他は、データベースの更新を制御できる変更を処理するためのフレームワークを提供します。

6. アプリケーションをORMのオブジェクトに結合したいですか、それともPOCOを処理し、永続化のためのアダプターを使用したいですか？
   前者は通常、簡単に処理できますが、どこでもORM固有のデータオブジェクトに依存関係を作成し、後者は少し柔軟性があり、コードが少し増えます。

7. オブジェクトをリモートで転送する必要がありますか？
   リモートサーバーからオブジェクトを取得する場合、すべてのORMが同じというわけではありません。できることまたはできないことをよく見てください。効率的なものもあれば、そうでないものもあります。

8. 助けを求める人はいますか？
   優れた商用サポートはありますか？プロジェクトを取り巻くコミュニティはどれほど大きくて活発ですか？
   既存のユーザーが製品に関して抱えている問題は何ですか？
   彼らは迅速な解決策を得ていますか？

私が見たいくつかのORM：

• 
  developer ExpressのXPO：小さくてシンプルで、コード中心です。アプリケーションフレームワークeXpressAppに使用します。
• NHibernate
  は無料ですが、学習曲線はかなり急です。たくさんのグッズがありますが、断片化されたすべてのドキュメントで実際に関連するものを見つけるのは困難です。
• LLBLGen Proは
  非常に成熟したプロジェクトであり、最も単純なものではなく、多くの考えがそこに置かれています。
• 
  そこにエンティティフレームワーク GEtting。他のより成熟したORMと比較するとまだ少し若いですが、最後のリリースはかなり良く、MSはリッスンしています。
• DataObject.Net
  は有望に見えますが、重要なプロジェクトを危険にさらすために少し新しいものです。しかし、かなり活発です。

もちろん他にもたくさんあります。

いくつかのパフォーマンスベンチマークをリストしている論争の的となっているサイトORM Battleを見ることができますが、生の速度は必ずしもプロジェクトにとって最も重要な要素ではなく、ウェブサイトのプロデューサーはDataObject.Netであることに注意する必要があります。

私はNHibernateを使用していますが、かなり優れていることがわかりました。

私の場合、MS Sqlデータベースにリンクされていますが、他のデータベースに接続できます。

起動して実行するのにそれほど時間はかかりません-オブジェクトをモデルにマップするだけです-XMLファイルを使用しますが、コードで流inに実行できます。すばらしいコミュニティがあり、個人的には、Ayendeの仕事が非常に役立つことがわかりました。SQLプロファイリングツールであるNHProfを使用しています。

私はほとんどそのままの機能-まっすぐなオブジェクトマッピングを使用しますが、Hibernate Query Languageも使用しています。

悲しいことに、私の最後の3つの仕事では、3つの自家製ORMがありました。いずれの場合も、彼らは主にさまざまな理由で吸い込みました。

私は最近Entity Framework 4とそのPOCOサポートを評価しています（いいチュートリアルがここにあります）。それが自分の顔から離れており、データを収集するのではなく再びプログラミングしているような気分にさせてくれます。

ORMBattle.NETでのORM比較とベンチマーク

Linq to Sqlが大好きです。それはシンプルで、まともなデザイナーがいます。しかし、Entity Frameworkを支持して終わらせたいと考えています。オブジェクトをカスタマイズできるように、ジェネレーターを変更する機能を活用できるようにしたいと思います。

（私の意見では）これらが他のものよりも優れている最大の利点は、VSですぐに使えることです。これは、MSに翻弄されているという点でも否定的です（Linq to Sqlを参照）。

[免責事項：DevExpressで働いています]

ここで、DevExpressアプリケーションフレームワークによって作成された典型的なアプリケーションのスクリーンショットを見ることができます。このページには、当社製品の非常に短いレビューも含まれています。理由の詳細については、Webサイトの各製品ページをご覧になることをお勧めします。

DevExpress XAFとXPO については、ここでアプリケーションフレームワークを選択する理由を説明します。さらに、サポートとドキュメントも提供しますが、これも重要であり、言及する価値があります。ご質問がある場合はお気軽にお問い合わせください。

NHibernate + Fluent NHibernateを使用し、小さなプロジェクトではLinq-to-Sqlを使用します。その理由は次のとおりです。

1）（主な理由ではない）NHibernateは開発者の間でより高い「尊敬」要因を持っているようです（これは本当ですか？）、

2）linq-to-SQLと比較して、nHibernateはDbオブジェクトと1対1をマッピングしないエ​​ンティティ間のORMマッピングを可能にします

3）nHibernateとEntity Framework 4.0を広範囲に比較したことはありませんが、良い比較はこちらです：http ://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernateには多少の学習曲線があり、そのXMLマップは非常に冗長な場合がありますが、Fluent Nhibernateサイトのドキュメントから始めて、逆方向に進んでください。

それらはすべて長所と短所の異なる組み合わせを持っているため、「最高の」ORMフレームワークはありません。開発者が1つの領域をより良くすることに集中することを選択した場合、最初にモデル対データベース）。

一方、非常に優れたものがいくつかあり、そのいくつかは他の人よりもあなたの個人的な状況や哲学により良くマッチします。

編集：その価値のために、私は現在Linq to SQLを使用しています-主にその理由は、最小限の労力で多くの権利を果たし、おそらく「そこにあるから」再びEntity Frameworkに進むからです（同様にEF4の多くは正しく、いくつかの問題もあります）。特に後者の場合、懸念はパフォーマンスでなければなりませんが、ほとんどの場合、それは大きな問題ではなく、モデル（L2SおよびEF）からダイナミックデータとODataを実行する機能は、「安い」が勝ちます。

DevExpress XPOをご覧になることをお勧めします。これとDevExpress XAFにより、学習曲線を超えた開発者の生活が楽になります。

Entity Frameworkには幸運がありました。私たちの状況はやや珍しいですが、レポートチームのためにデータ収集を行うため、実際にデータベースを設計します。DBを取得し、EFを使用してそこからデータアクセスクラスを生成します。私たちにとってはうまく機能しますが、大量のデータをロードするだけなので、よりトランザクションの多い環境でどれだけうまくいくかを保証することはできません。

NHibernate（+ FluentNHibernate）がデフォルトのオプションです。非常に柔軟で、拡張可能で、堅牢です。膨大な数のユーザーがおり、非常に積極的に管理されています。欠点は、急な学習曲線です。

MindScapeのLightSpeedはシンプルでユーザーフレンドリーですが、それでもかなり柔軟で機能的です。L2S / EFのようなデザイナーサーフェスとUnitOfWork実装があります。

まあ、「最良の」選択はありませんが、通常の古いLinq to SQLはあなたのニーズを満たしていると言えます。それは「本当の」ORMそのものではありませんが、非常に軽量であり、それが理にかなっている場合は、気付かないうちにコードを記述する柔軟性を提供します。つまり、dbmlファイルを保持する以外にLinqを意識する必要なく、通常どおりコードを記述し続けることができます。RepositoryまたはGatewayパターンを使用して抽象化を記述することができ、L2SはORMの主な役割を果たします。これは、オブジェクトとリレーショナルの不一致を回避することです。

Entity Frameworkは少し重く、ほんの少し手を出しただけですが、基本的なLinq to Sqlよりも「あなたの顔に」見えますが、EFはLinqよりも真のORMです。ORMであなたが探しているすべての基準を調べます。生のSQLを記述する必要がなく、さらに悪いことに、何百ものストアドプロシージャが必要なためです。生のLinq to Sqlが提供できない追加機能が必要ですか？これらの質問に答える必要がありますが、簡単な要件（「軽量で使いやすい」）に基づいて、LinqはSubsonicのようなものより少し簡単で、Visual Studioに組み込まれていると思います。

ECO :)ステートマシンと実行可能なOCL（つまりEAL）のサポートを含めながら、ORMをはるかに超えています。12個のドメインクラスの制限がある無料版が存在しますが、これは小規模なプロジェクトにはかなり適していると思います。