リポジトリはIQueryableを返す必要がありますか？

のインスタンスを返すリポジトリを持つプロジェクトをたくさん見てきましたIQueryable。これにより、追加のフィルターとソートをIQueryable他のコードで実行でき、異なるSQLが生成されます。私はこのパターンがどこから来たのか、それが良いアイデアであるかどうかに興味があります。

私の最大の懸念はIQueryable、データベースが列挙されると、しばらくするとデータベースにヒットするという約束です。これは、エラーがリポジトリの外部にスローされることを意味します。これは、Entity Framework例外がアプリケーションの別のレイヤーでスローされることを意味する場合があります。

また、過去（特にトランザクションを使用する場合）に複数のアクティブな結果セット（MARS）の問題に遭遇しましたが、このアプローチはこれがより頻繁に発生するように聞こえます。

リポジトリコードを終了する前に、常にLINQ式を呼び出すAsEnumerableかToArray、各LINQ式の最後でデータベースがヒットすることを確認しました。

IQueryableデータレイヤーのビルディングブロックとして戻ることが役立つかどうか疑問に思っています。あるリポジトリが別のリポジトリを呼び出してさらに大きなIQueryable。

IQueryableを返すことにより、リポジトリのコンシューマーに確実に柔軟性を与えることができます。結果を絞り込むという責任をクライアントに委ねます。これは当然、利益と松葉杖の両方になる可能性があります。

良い面として、必要なデータを取得するために（少なくともこのレイヤーで）大量のリポジトリメソッド（GetAllActiveItems、GetAllNonActiveItemsなど）を作成する必要はありません。好みによって、これは良いことも悪いこともあります。あなたはします（/必要があります）あなたの実装が付着行動の契約を定義する必要がありますが、それはどこに行くかはあなた次第です。

そのため、リポジトリの外にザラザラした検索ロジックを配置し、ユーザーが望む方法で使用できるようにすることができます。そのため、IQueryableを公開すると、柔軟性が最も高くなり、インメモリフィルタリングなどとは対照的に効率的なクエリが可能になり、特定のデータ取得メソッドを大量に作成する必要性を減らすことができます。

一方、今ではユーザーにショットガンを与えています。彼らはあなたが意図していなかったかもしれないことを行うことができます（.include（）の過剰使用、重い重いクエリの実行、それぞれの実装でのメモリ内フィルタリングの実行など）。全権アクセス。

そのため、チーム、彼らの経験、アプリのサイズ、全体的な階層化とアーキテクチャに依存します…それは依存します：-\

IQueryableをパブリックインターフェイスに公開することはお勧めできません。その理由は基本的です。言われているように、IQueryableの実現を提供することはできません。

パブリックインターフェイスは、プロバイダーとクライアント間の契約です。そしてほとんどの場合、完全な実装が期待されます。IQueryableはチートです：

1. IQueryableを実装することはほぼ不可能です。そして現在、適切な解決策はありません。Entity Frameworkでさえ多くのUnsupportedExceptionsを持っています。
2. 現在、クエリ可能なプロバイダーはインフラストラクチャに大きく依存しています。Sharepointには独自の部分実装があり、My SQLプロバイダーには個別の部分実装があります。

リポジトリパターンは、階層化による明確な表現を提供し、最も重要なのは実現の独立性です。したがって、将来のデータソースを変更できます。

問題は、「データソースの置換の可能性があるべきですか？」です。

明日のデータの一部をSAPサービス、NoSQLデータベース、または単にテキストファイルに移動できる場合、IQueryableインターフェイスの適切な実装を保証できますか？

（これが悪い習慣である理由についてのより良い点）

現実的には、遅延実行が必要な場合、3つの選択肢があります。

• このようにしてください- IQueryable。
• 特定のフィルターまたは「質問」の特定のメソッドを公開する構造を実装します。（GetCustomersInAlaskaWithChildren、以下）
• 厳密に型指定されたフィルター/ソート/ページAPIを公開し、IQueryable内部で構築する構造を実装します。

私は3番目の方法を好みます（2番目の方法も同僚が実装するのを手伝いました）が、明らかにいくつかのセットアップとメンテナンスが関係しています。（T4が助けに！）

編集：私が話していることを取り巻く混乱を解消するために、IQueryableから盗まれた次の例を考えてみましょう。犬を殺す、妻を盗む、生きる意志を殺すなど

このようなものを公開するシナリオでは：

public class CustomerRepo : IRepo 
{ 
     private DataContext ct; 
     public Customer GetCustomerById(int id) { ... } 
     public Customer[] GetCustomersInAlaskaWithChildren() { ... } 
} 

私が話しているAPIを使用するとGetCustomersInAlaskaWithChildren、柔軟な方法で表現（または他の条件の組み合わせ）できるメソッドを公開でき、リポジトリはそれをIQueryableとして実行し、結果を返します。ただし、重要なことは、リポジトリレイヤー内で実行されるため、遅延実行の利点を活用できることです。結果を取得した後でも、LINQ-to-to-objectsを思う存分使用できます。

このようなアプローチのもう1つの利点は、POCOクラスであるため、このリポジトリがWebまたはWCFサービスの背後に存在できることです。AJAXや、LINQについて最初に知らない他の呼び出し元に公開される可能性があります。

正当な答えは1つだけです。それは、リポジトリの使用方法に依存します。

極端な例では、リポジトリはDBContextの非常に薄いラッパーであるため、データベース駆動型アプリの周りにテスト容易性のベニアを注入できます。CRUDアプリはこれを必要としないため、LINQフレンドリDBを使用せずに、これを非接続で使用できるという現実世界の期待はありません。確かに、なぜIQueryableを使用しないのですか？IEnumarableを使用すると、ほとんどの利点が得られ[実行：遅延実行]し、それほど汚く感じないので、おそらくIEnumarableを好むでしょう。

あなたがその極端に座っていない限り、私はリポジトリパターンの精神を利用して、基礎となるデータベース接続の意味を持たない適切な実体化されたコレクションを返そうと努力します。

 > Should Repositories return IQueryable?

データベースまたは他のIQueryableプロバイダーから隔離してビジネスロジック（=リポジトリ消費者）をテストするためのモックリポジトリを簡単に作成する方法がないため、テスト駆動開発/ユニットテストを実行する場合はNOです。

純粋なアーキテクチャーの観点から見ると、IQueryableは漏れやすい抽象化です。一般的に、ユーザーにあまりにも多くのパワーを提供します。そうは言っても、それが理にかなっている場所があります。ODataを使用している場合、IQueryableを使用すると、簡単にフィルター処理、並べ替え、グループ化などが可能なエンドポイントを非常に簡単に提供できます。そのようにして、データを事前にフィルター処理し、IQueryableメソッドのみを使用して、クライアントが結果をカスタマイズできるようにします。

私もそのような選択に直面しました。

それでは、プラス面とマイナス面をまとめましょう。

ポジティブ：

• 柔軟性。クライアント側がたった1つのリポジトリメソッドでカスタムクエリを構築できるようにすることは、間違いなく柔軟で便利です。

マイナス面：

• テスト不可。（実際には、通常はORMである、基になるIQueryable実装をテストします。ただし、代わりにロジックをテストする必要があります）
• 責任を曖昧にする。リポジトリのその特定のメソッドが何をするかを言うことは不可能です。実際、それはデータベース全体で好きなものを返すことができる神の方法です
• 安全でない。このリポジトリメソッドでクエリできるものに制限はありませんが、場合によっては、そのような実装はセキュリティポイントから安全でない可能性があります。
• キャッシュの問題（または一般的には、前処理または後処理の問題）。たとえば、アプリケーションのすべてをキャッシュすることは一般的に賢明ではありません。何かをキャッシュしようとすると、データベースに大きな負荷がかかります。しかし、リポジトリメソッドが1つしかない場合、そのクライアントがデータベースに対して事実上すべてのクエリを発行するために使用する方法は？
• ロギングの問題。リポジトリレイヤーで何かをログに記録すると、最初にIQueryableを検査して、この特定の呼び出しがログに記録されるかどうかを確認できます。

このアプローチの使用はお勧めしません。代わりに、いくつかの仕様を作成し、それらを使用してデータベースを照会できるリポジトリメソッドを実装することを検討してください。仕様パターンは、一連の条件をカプセル化する優れた方法です。

リポジトリでIQueryableを公開することは、開発の初期段階では完全に受け入れられると思います。IQueryableと直接連携し、並べ替え、フィルタリング、グループ化などを処理できるUIツールがあります。

そうは言っても、レポジトリを汚すだけで1日に電話するのは無責任だと思います。一般的なクエリに対して便利な操作とクエリヘルパーを使用すると、クエリのロジックを集中化しながら、リポジトリのコンシューマーに小さなインターフェイスサーフェスを公開できます。

プロジェクトの最初の数回の反復では、リポジトリでIQueryableを公開することで、より迅速に成長できます。最初の完全なリリースの前に、クエリ操作をプライベートまたは保護し、ワイルドクエリを1つの屋根の下に置くことをお勧めします。

私が見たのは（そして私が自分で実装しているのは）次のことです：

public interface IEntity<TKey>
{
    TKey Id { get; set; }
}

public interface IRepository<TEntity, in TKey> where TEntity : IEntity<TKey>
{
    void Create(TEntity entity);
    TEntity Get(TKey key);
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> GetAll(Expression<Func<TEntity, bool>> expression);
    void Update(TEntity entity);
    void Delete(TKey id);
}

これができることは、LINQyビジネスを公開せずにIQueryable.Where(a => a.SomeFilter)実行concreteRepo.GetAll(a => a.SomeFilter)することにより、レポジトリでクエリを実行できる柔軟性を持たせることです。