パフォーマンスを改善するためのものを探していたときに、この投稿に出くわしました。現在、私のアプリケーションでは、あちこちに戻っIList<>てきています。これらすべてのリターンをに変更するのは良い考えAsQueryable()ですか？
これが私が見つけたものです-
AsQueryable()-コンテキストは開いている必要があり、適切に破棄する必要があるデータベースコンテキストの存続期間を制御することはできません。また、実行は延期されます（リストと比較して「より高速なフィルタリング」）IList<>List<>-ベアボーンで軽量な実装を提供するため、 これを優先する必要があります。また、いつ他のものよりも優先されるべきですか？基本は知っていますが、アプリケーションでいつ、どのように正しく使用すればよいのか、まだはっきりしていません。次回は何かを返す前にそれを心に留めようとするので、これを知っておくのは素晴らしいことです..どうもありがとう。
基本的に、必要な最も広いタイプを参照するようにしてください。たとえば、ある変数がとして宣言されている場合List<...>、それに割り当てることができる値のタイプに制約を設定します。シーケンシャルアクセスのみが必要な場合があるため、IEnumerable<...>代わりに変数を宣言するだけで十分です。これにより、他のタイプの値とLINQ操作の結果を変数に割り当てることができます。
変数にインデックスによるアクセスが必要であることがわかった場合は、変数をIList<...>単にList<...>ではなくとして宣言して、他のタイプの実装を変数IList<...>に割り当てることができます。
関数の戻り型については、ユーザーによって異なります。関数が正確に返すことが重要だと思う場合は、正確List<...>に返すように宣言しますList<...>。唯一の重要なことがインデックスによる結果へのアクセスである場合、おそらく正確に返すように自分自身を制約する必要はないので、List<...>return typeをとして宣言することができますIList<...>（ただし、実際にList<...>はこの実装のインスタンスを返し、場合によってはサポートする別のタイプのインスタンスを返しますIList<...>後で）。繰り返しになりますが、関数の戻り値について重要なのは列挙できることだけであることがわかった場合（そして、インデックスによるアクセスは必要ありません）、関数の戻り型をに変更してIEnumerable<...>、自由度を高める必要があります。
さて、約AsQueriable、再びそれはあなたの論理に依存します。不必要な計算を回避するのに役立つ可能性があるため、遅延評価の可能性が良いと思う場合、または別のクエリの一部として使用する場合は、それを使用します。結果を「具体化」する必要があると考える場合、つまり、現時点で計算する必要がある場合は、を返す方がよいでしょうList<...>。後で計算すると別のリストになる可能性がある場合は、特に結果を具体化する必要があります。
AsQueriableデータベースでは、短期間の中間結果には使用するのが大体の目安ですがList、より長い時間内に使用される「最終」結果には使用します。もちろん、マテリアライズされていないクエリがぶら下がっていると、データベースを閉じることができなくなります（データベースの実際の評価の時点では、データベースはまだ開いている必要があるため）。
SQL Serverに対してこれ以上クエリを実行する予定がない場合は、メモリ内データを生成するため、IListを返す必要があります。
パフォーマンスが心配な場合は、できるだけ少ないDBリクエストでクエリを実行し、最もよく使用されるクエリをキャッシュするようにしてください。バッチアプローチを使用してリクエストプロセス時間を大幅に短縮することは非常に一般的です。
DBからデータを取得するためにどのORMを使用しますか？NHibernateを使用する場合は、 Future、Multi Criteria 1、Multi Criteria 2、およびMultiQueryの使用方法についてこの投稿を参照してください。
ご挨拶。