IRepositoryからIQueryableを返す

リポジトリパターンを使用して、一般的な使用のために、データセット（テーブル）のIQueryableを返すことは適切ですか？

これは多くの場合に非常に便利です。特に、そのインターフェイスを利用する外部ライブラリ、たとえば、UI要素をソート/フィルタリングしてバインドするプラグインを使用する場合に便利です。

ただし、IQueryableを公開すると、デザインにエラーが発生しやすくなる場合があります。これと遅延読み込みの誤った使用を組み合わせると、パフォーマンスが大幅に低下する可能性があります。

一方、使用方法ごとにアクセスメソッドを用意することは冗長であり、多くの作業（ユニットテストなど）も必要です。

Mark Seemannがこのテーマについて優れたブログ投稿を公開しています：IQueryable is Tight Coupling。彼は最後の部分（私の強調）でそれをうまくまとめています：

これはすべて理論的な演習だと思うかもしれませんが、実際には重要です。Clean Codeを作成するときは、APIの機能が明確になるようにAPIを設計することが重要です。

このようなインターフェースは誤った保証をします：

public interface IRepository
{
    IQueryable<T> Query<T>();
}

LSPとPostelの法則によれば、返されたインスタンスに対して（どんなに複雑であっても）クエリ式を記述できることが保証されているように見え、常に機能します。

実際には、これは決して起こりません。

そのようなインターフェースを定義するプログラマーは常に特定のORMを念頭に置いており、その特定のORMに対して安全であることがわかっている境界内に留まる傾向があります。これは漏れやすい抽象化です。

特定のORMを念頭に置いている場合は、それについて明確に説明してください。インターフェースの背後に隠さないでください。ある実装を別の実装に置き換えることができるという錯覚を引き起こします。実際には、それは不可能です。イベントストアを介して実装を提供しようとしていると想像してください。

ケーキは嘘です。

Entity FrameworkのようなORMのは、あるリポジトリと作業パターンの単位の実装。それらを別のものにラップする必要はありません。

これについてはコンセンサスはありません。私の意見と経験では、リポジトリは特定の用途を持つオブジェクトを返す必要があります。少なくとも、DDDでEric Evensによって定義されたリポジトリパターンを使用する場合。リポジトリは、ビジネスロジック、永続性、およびファクトリを接続する「ブリッジ」です。

より永続的にアクセスしたい場合は、ゲートウェイパターンを探している可能性があります。

ただし、ここで言うことから、その持続性への露出を非表示にして、プロキシパターンが便利になるようにします。