.net - NHibernateとEF4.1+

Question

私は主にこの分野で2つのORMの長所と短所を決定しようとしています。

SQL Server2008R2および2012との互換性。
- 既存のMSテクノロジスタックの不十分なサポートをデバッグするためのリソースがないため、これは非常に重要です。
- また、2012年以降の計画はほぼ終了しており、それに移行する計画があります。
.NET 4.0および4.5のサポート（今後）
- 上記とほぼ同じ理由で、これも非常に重要です。
トランザクション処理とテーブルヒント。forcescan forceeek、コミットされていない読み取り。
- 多くの場合、クエリオプティマイザはその仕事をうまく行いますが、それ以外の場合は、何をすべきかを柔軟に指示したいと思います。
会話、セルフトラッキングのアタッチとデタッチのサポート
- これはやや基本的なことです。私はセッションを長期間開いたままにするのが嫌いです。特に分散コンピューティング/Webファーム環境で。
データを破壊することなく、コードの最初の開発を処理し、スキーマを作成および更新する機能。
- EF 4.1はこの点で望んでいるようですが、4.3は飛躍的でより優れています。また、NHの個別のマッピングクラスよりもデータアノテーションの方が好きです。理由は、クラスで送信できるようにし、そこからマッピングクラスのメソッドを拡張せずに永続性モデルを作成できるようにしたいからです。
IRepositoryパターンのサポート
LINQのサポート
- 上記の（6）にある程度結びついているので、linqを本当に適切にサポートしたいと思います。開発者が低レベルの実装をいじくり回して、特定のORMに固執することを望んでいません。
パフォーマンス
データをアプリケーション層にロードすることなく、一括CRUD操作をサポートします。例えば。特定のテーブルの列のすべての行を1つインクリメントしたい。これをメモリにロードしたくないので、行を1つずつインクリメントします。これは、このような単純な操作には夢中になるでしょう。Linq2Sqlは、この種のことを処理するためにMagiqを持っていましたが、NHとEFには何がありますか？
キャッシング、積極的な読み込み、遅延読み込み、ナビゲーションプロパティ。
- 率直に言って、暗黙のうちに行われると、これらのことは嫌いです。キャッシュされているもの、古いものと新しいものを区別するのが難しい理由。EFでは、通常、すべてのナビゲーションプロパティを削除します。これは、これらのプロパティに上位5をロードしたくないためです。これは、現在の操作に必要なものですが、さらに下流では、別の開発者が不正確なカウントを実行しようとします。
- したがって、私の個人的なポリシー-他に正当な理由がない限り、すべてのSOAはステートレスになります。データを参照する必要がある場合は、永続性から取得してください。遅くなりますが、コードはより読みやすく柔軟になります。
- キャッシングについても同様です。分散環境にあるので十分に複雑なので、すべてのキャッシングを非常に明示的にしたいと思います。開発者がキャッシュに対してコーディングしたい場合は、ORMに対してコーディングするのではなく、そうする必要があります。実際には古いデータを取得しているときに、永続性から新しいデータをプルしているように見せます。
- ここで問題となるのは、NHibernateには、キャッシング、熱心な/遅延読み込みを、現在EFで利用可能なものよりもはるかに明確にする概念/抽象化がありますか？この場合、開発のしやすさはあまり気にせず、明快さと明確さを気にします。

また、私はOSS対所有者の議論をあまり気にしません。チームは、内部を覗き込んで他の人のコードをいじり始める時間をとることができません。私は何よりも「うまくいく」という角度に関心があります。

score 10 · Accepted Answer

これらの問題のいくつかについて別の質問で書きましたが、これに1つずつ答える価値があると思います。

どちらもすべてのSQLServerバージョンと互換性があります
どちらも.NET4.xと互換性があります。NHはまだ3.5を目標としていますが、これは問題ではありません。
どちらにもトランザクション処理があります。どちらもネイティブクエリ言語のクエリヒントをサポートしていませんが、どちらもSQLを使用できます。
どちらも、切断されたエンティティを再接続できます。私は個人的にこれは良い習慣ではないと思います（私はDTOを渡すことを好みます）
EFでは、スキーマの移行はより成熟しており、柔軟性があります。マッピングは、NHでははるかに優れています。属性を使用したマッピングをサポートしています。これは、EFの同等のものよりもはるかに強力であり、基本的なもの（10進数フィールドの精度の指定など）もサポートしていないことがすぐにわかります。
どちらの上にリポジトリを実装することもできます。
どちらもLINQをサポートしています。EFは、非常に非効率的なクエリを生成することもありますが、より広範囲のクエリをサポートします。開発慣行をおろそかにしてはいけません。各クエリメソッドには利点があり、優れた開発者はオプションを知っている必要があります。
NHは、マッピングの柔軟性と、バッチ処理、キャッシング、およびDMLステートメントのサポートにより、通常、パフォーマンスが向上します。
EFはバルク（DML）操作をサポートしていません。NHは、SQLステートメントと非常によく似たINSERT / UPDATE / DELETEステートメントを使用しますが、オブジェクトモデルを使用します（たとえば、明示的な結合の代わりにドット構文を使用して条件を指定できます）
- EFはキャッシング、期間をサポートしていません。生産の準備ができていないサポートされていないサンプルがいくつかあります。NHibernateでのすべてのキャッシュは明示的です（キャッシュするエンティティ、コレクション、クエリ、期間などを指定します）。memcachedのような分散キャッシュをサポートしているため、古いキャッシュデータも処理できます。
- どちらも、参照とコレクションを明示的にロードすることを可能にします。NHは、私の意見では、モデルをFKで汚染しない、より優れたプロキシ設計を備えています（これは長いトピックです。必要に応じて、フォローアップの質問を投稿できます）。そしていつものように、各関係をどのようにロードする必要があるかを指定するときは、より柔軟性があります。

一言で言えば、NHはより柔軟でパフォーマンスが優れており、手に負えません。EFは、より優れた移行サポート、わずかに簡単な学習曲線、およびより完全なLINQプロバイダーを備えています。

score 8 · Accepted Answer

まず第一に、私はさまざまな面でNHibernateを好みます。Entity Frameworkは、バージョン5.0でも何かを見逃しています。

NHibernateで新しいタイプを追加するのは非常に簡単なので、SQL Server 2012に新しいタイプがある場合は、相対的な方言/プロバイダーを実装できますが、コミュニティは常に機能しています
NHチームがFW4.5のサポートに取り組んでいることは知っていますが、EFは5.0からサポートしています。
NHを使用すると、やりたいことがすべてできます
NHは、エンティティを再接続するためのMergeメソッドをサポートしています。EFも
EFは命名規則をサポートしていませんが、NHはサポートしています。また、DataAnnotationsに基づく自動マッパーを作成しています。ここでは古いバージョンへのリンクです。新しいバージョンを2週間待ちます。
NHまたはEFを使用すると、リポジトリと作業単位のパターンでデータレイヤーを実装できます。このパッケージも、NuGetでリリースする必要があります。
EFはLINQを完全にサポートしますが、NHはサポートしませんが、拡張ポイントを使用してパッチを適用できます
パフォーマンスは同じレベルだと思います。NHはセカンダリレベルのキャッシュをより適切にサポートするため、データベースへのヒットを簡単に防ぐことができます。
NHのバッチサポートが改善されました。EF （特に5.0）についてはわかりません。
NHは拡張ポイントの実装が優れているため、プロキシ/キャッシング/ロギングはEFよりも強力ですが、EFでは、必要なものを取得するためのラッパーを作成できます。

最後に、マッピングがより柔軟であるため、NHを使用するとDDDパターンを実装するのが簡単になります。

score 6 · Accepted Answer

bltoolkitを使用できます;）-> http://www.bltoolkit.net/Doc.Linq.ashx

これを読むのに2分かかります-> http://www.bltoolkit.net/Doc.LinqModel.ashx

しかし要するに

非常に優れたLinqサポート
DML操作（nr 9）
優れたパフォーマンス/バルクサポート
素晴らしい生成されたSQL
列挙型サポート;-)
遅延読み込み/エンティティ追跡/特別な魔法のキャッシュはありません。通常問題を引き起こすこれらのこと
魔法の機能がない->抽象化が少ない->リークが少ない->トラブルが少ない->学習曲線が小さい

ところで、nr 3を実行します。これには、テーブル値のUDF、ヒント、およびその他のテーブル装飾をサポートする属性TableFunctionとTableExpressionがあります。したがって、たとえば、Linqステートメントで使用する独自の拡張メソッドを記述できます。

[TableExpression("{0} {1} WITH (TABLOCK)")]
public Table<T> WithTabLock<T>()
    where T : class 
{
    return _ctx.GetTable<T>(this, ((MethodInfo)(MethodBase.GetCurrentMethod())).MakeGenericMethod(typeof(T)));
}

その後

using (var db = new TestDbManager())
{
    var q =
        from p in new Model.Functions(db).WithTabLock<Parent>()
        select p;

    q.ToList();
}

サンプルDML操作

  db.Employee
    .Where(e => e.Title == "Spectre")
    .Set(e => e.Title, "Commander")
    .Update();

score 1 · Accepted Answer

他の答えに追加するだけです...

Ricardo Peresは、数日前にNHibernateとEntityFrameworkの非常に優れた公平な比較を作成しました。それはあなたの研究に役立つかもしれません。

ここで見つけることができます：http ：//weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx

score 1 · Accepted Answer

あなたはそれらのどちらも欲しくない。任意のテーブルヒントを指定することはできません。また、希望するほど柔軟になることもありません。

これらすべてが要件である場合、それらを満たすORMは地球上にありません。

編集：

あなたのコメントに基づいています。nHibernateは最大のパワーを提供しますが、モデルのセットアップが複雑になります。役立つかもしれないいくつかのツールがありますが、それぞれに長所と短所があります。

EFは構成と使用が簡単ですが、それほど強力ではありません。nHibernateは反対です。パワーと複雑さのどちらかを選択する必要があります。

ところで、一括操作などに関しては、そのような操作のフレームワークから直接SQLを発行できます。または、ストアドプロシージャを呼び出します。

.net - NHibernateとEF4.1+

5 に答える 5

Related

Reference