NHibernateとリポジトリパターン

Question

Nhibernate +リポジトリパターンを使用するために推奨されるアプローチは何ですか？

私はどのような道を取るべきかわからないほど多くの異なる記事や意見があります。例えば、Take this lengthy articleである。これはQueryオブジェクトの例を示していますが、各具体的なリポジトリはそのコンストラクタにISessionを受け入れます。私のBL（ビジネス層）のNHセッションはどうしたらいいですか？

1. それらのそれぞれは、特定のメソッドの束を持つ、リポジトリの束を作成しますか？
   BLは現在NHibernate（Repository is the new Singleton）を認識することが許可されているので、それはあまりにも多くの作業ですか？

2. 単一の一般的なリポジトリを作成しますが、IQueriable<T>を公開し、毎日のようにBLに
   をLINQを使用して、LINQツーNHibernateのが処理することができなくなり、クエリがある（または私は微調整する必要があります100回のクエリで手動でSQLを実行します）。カスタムリポジトリメソッドでは簡単ですが、LINQに依存するコードでは不可能です。場合によってはLINQが壊れているという理由だけで両方を使用するのはナンセンスです。

3. クエリオブジェクト？
   QueryOverもNH固有であり、これはBLが再びDAL実装を認識していることを意味します。

4. さらに別のアプローチですか？明らかに

、私はどこか、多分作業単位パッテンを使用して（その周りの多くの異なる実装もありますが）取引を管理できるようにする必要があります。

Answer 1

ソフトウェアアーキテクチャの世界には多くの相反する意見があり、その多くは非常によく確立されています。

1）はい、各集約ルートのリポジトリを定義することは過度になる可能性がありますが、そのルートのデータを取得する方法は固有であり、カスタムリポジトリで制御できるようにすることができます。 Ayendeの記事は、ソリューションを「オーバーアーキテクト」したいという典型的な開発者の要望に非常によく耳を傾けています。多くの場合、機能性を損なうものです。

2）NHibernateでLINQを使用することもできますが、これを行う場合は、条件照会やHQLを使用するようにする必要があります。その段階では、非常に多くの例外を入れているかもしれませんが、抽象化の最初の点が何であったのか疑問に思うでしょう。

3）QueryOverは、タイプセーフなラッパーの基準クエリであり、これだけで私にとってはるかに魅力的です。私はしばしば、彼らが提供する完全なコントロールの基準に戻ってくることがよくあります。フォールバックは、しばしば「魔法の弦」を使用しなければならないということです。これは本質的にNHibernateをデータアクセスの抽象化にします。実際には、ほとんどのリポジトリはCRUDメソッドを提供するだけなので、より良い抽象化になります。リポジトリはクエリの仕様（正確にはQueryOverの仕組み）を処理できるはずです。

トランザクションに関しては、フレームワークによって異なります。現実には、アプリケーションで作業単位のパターンを使用してその実装を隠すことは現実的で有益ではないと思いますが（抽象化することができますが、何がポイントですか - 実際にORMを変更しますか？）

ASP.NETを使用している場合、（最低でも）要求の開始時にトランザクションを開始し、例外をロールバックし、最後にコミットします。

WinFormsを使用している場合は、各UIタスクの作業期間を作業単位と考える必要があります。

Answer 2

サイトは今ダウンしているようだが、私は本当にボブ・クレイヴンのアプローチのように、いくつかの大きなプロジェクトでそれを使用している：

http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/ EDIT：Google cache version of the link

彼はジェネリックとデータアクセスのためのUOWパターンを使用しています。

はい、SQLに落ちる必要がある場合は少し苦労しますが、私はそれを抽象化できるデータサービス層を使用します。私。データサービス層は、可能な限り汎用DAOを使用し（時間の90％）、他の場所ではバニラSQL /その他のフレームワークを使用します。