最近、私たちはnHibernateを3.2にアップデートしました。 クエリを書き込むための2つの新しいオプション、Query（LINQ）またはQueryOver（iCriteria）が追加されました。Nhibernate 3.2 QueryOverとQueryOver
私が読んだものから、QueryOverは複雑 クエリのためにNHibernateは、より強力に捧げられています。 一方、LINQは普遍的です。明日ORMを変更すると、クエリは のままです。私がLINQを使用するもう一つの重要な理由は、LINQでもっと多くのドキュメントがQueryOverよりも と多く見つかったという事実です。
は実は、私は、LINQを使用することを好む、と私は私がこれを行うべきではない理由を決定的な理由がないことを確認したいです。
事前のおかげで、今のよう
は、残念ながら彼らの制限があり、両方とクエリのほとんどはうまく動作Linq2SQLの表現に一致するようにNHibernateはチームでやるべき仕事がたくさんあります。
時間のほとんどを私はLINQの（Query）を使用するが、それは、グループ化を伴う比較的単純なクエリにいくつかの予期せぬ問題や（byte?https://nhibernate.jira.com/browse/NH-2812の悪名高い「無効なキャスト」のような）いくつかの微妙なバグがあります。基準api（QueryOver）に切り替えると、通常役立ちます。
直線推薦を与えること、次いで不可能である（3.2）今のように。私はLinqに固執し、問題に遭遇したときに一時的に基準に切り替え、将来のバージョンでバグや制限が取り除かれたとき、元に戻ってすべてのものをLinqに書き直してプライマリクエリ言語として機能させる必要があります。
あなたのORMをスワップアウトのチャンスは誰にも非常にスリムです。
はQueryOverとクエリの両方が彼らの長所と短所を持っています。
しかし、NHの利点は、あなたが簡単にそれのいずれかの間フリック機能を問い合わせるだということです。私が働いているところでは、QueryOver（主に）、Query、HQL、そして時にはSQLを組み合わせて使用します。
NHからの多くのLINQクエリは、EF、LightSpeed、またはORMの選択肢に簡単に変換されますが、LINQプロバイダに組み込まれているNH固有のLINQのヒープ全体がLINQプロバイダに組み込まれているため、任意の点でORMをスワップアウトします。
QueryOverクエリではクエリよりも優れたSQLが生成され、その逆もあります。したがって、生成されたSQLが効率的であることを確認するために、
LinqとQueryOverのどちらかを選択する必要はありません。任意の状況に最も適したものを使用することができます。 Linqに関するさまざまなORMによってサポートされているものにはいくつかの重複がありますが、サポートするものとバグのある場所には違いがあります。私は個人的にQueryOverがドキュメントの方法の多くを必要とせずに非常に使いやすいと判断しました。 –