Linq2Nibernate を使用する場合、リポジトリが IQueryable を返すようにする方が良いですか?
私の理解では、Linq を使用して Nibernate を使用する場合、クエリは .First() または Single() ect を呼び出すまで「起動」しません。では、すべてのインターフェイスから IQueryable を返して、式ツリーが起動する前に構築\操作できるようにするのが最善ではないでしょうか?
マイ リポジトリはサービスによって呼び出され、IServicie から継承されます。
編集：
まず、すべての回答に本当に感謝しています。しかし、質問に少し追加したいと思います。私はこのデザインに賛成です。テストに関する留保を完全には理解していません。プロセスがすべてのポイント、つまりすべてのフィルター ポイントでテストされている限り、実際には大きな違いは見られません。
添加：
リポジトリが IQuerrable を返さない場合、Linq2Nibernate を使用する意味はありますか?
個人的には、ないと思います。構成可能なクエリをリポジトリから公開する際の問題は、それらを完全に単体テストすることができなくなったことです。その動作 (および成功) は呼び出し元に委ねられています。たとえば、.Where(x=>SomeUnmappedMethod(x))（翻訳なしで）そうするかもしれません。ここにさらに追加しました。
(たとえば)IList<T>または を返すメソッドを修正T[]した場合、それが単体テストで機能する場合は、実際に機能するはずです (構成エラーがなければ)。また、DAL を分離してプロファイリングし、どの SQL (など) が実行されるかについて十分な確信を持つことができることも意味します。呼び出し元に基づいて変化する DAL をプロファイリング/最適化することはできません。
(LINQ-to-SQL の使用法に基づいており、具体的には LINQ-to-NHibernate ではありません)
それはあなたの「リポジトリ」を消費しているものに依存します（あいまいさのため引用符）。最後のレイヤー (UI) のようなものがリポジトリ クラスを消費してIQueryable を返さない場合、私は言います。ただし、UI レイヤーとデータ アクセス レイヤーの間に別のレイヤーがある場合は、はい、IQueryable を返し、中間レイヤーにクエリの実行を処理させます。
編集
データ アクセス レイヤー (DAL)/リポジトリのテストに関しては、実際のロジック (if ステートメントなど) がない限り、テストはほとんどまたはまったくないはずです。その時点で、フレームワークをテストしています。私の提案は、アクセス レイヤー (UI) と DAL の間に、BLL や IQueryable クエリの実行を処理する何かのような別のレイヤーを配置することです。そうすれば、リポジトリがクエリを返すことができ、BLL がそれらの実行を処理し、テストできるロジックを実行できる可能性があります。
私は IQueryable を使用しませんが、少し異なる方法で行う理由を説明します。