0

3層のUI、サービス層、リポジトリを備えたASP.NETアプリケーションがあります。

データベース内の製品に 検索機能を実装する必要があります。ProductRepositoryは私のリポジトリクラスであり、データベースからすべての製品を取得するメソッドのシグネチャは次のとおりです。

IQueryable<Product> GetAllProducts();

したがって、私のサービスレイヤーから使用します：

IProductRepository _ProductRepository = new ProductRepository(); 

IQueryable<Product> products = _ProductRepository.GetAllProducts();

たとえば、価格が100IQueryable<Product> productsを超える製品、またはcolor = "yellow"の製品だけを使用して、フィルタリングしたい場合。

ProductRepositoryだから私は、次のようなメソッドを作成する代わりに、疑問に思っていました。

IQueryable<Product> GetAllProductsByColor(int colorId)

サービスレイヤーIQueryable<Product>で、パラメーターとして受け入れ、そこで直接フィルタリングを実行する一連のメソッドを作成するのが良い方法かどうか疑問に思いました。

IQueryable<Product> FilterProducts(IQueryable<Product> products, Dictionary<string, object> filters)

ここで、は（propertyName、value）でDictionary<string, string>セットを表します。

このソリューションの利点は、複数のフィルターを適用する必要がある場合IQueryable<Product>、フィルター処理された製品セット間の交差を毎回取得するのではなく、既にフィルター処理されたものを渡すだけで済むことです。

それは良い習慣ですか（コンテキストを開いたままにしている限り）、それとも多層アーキテクチャパターンによって「許可」されていませんか？

4

1 に答える 1

2

IQueryableの実装を提供するものに依存すると思います。ほとんどの場合、IQueryableのユーザーが、1）インデックス付けされていないフィールドをフィルタリングする（したがって、データベースレイヤーがある場合は、大きなテーブルがある場合はデータベースレイヤーを選択する）か、2）任意のIQueryableを実行することを許可するリスクがあります。データベースに大きな負荷をかける操作（GroupBy、Joinなど）。

2）を防ぐために、1で問題ないと仮定します。通常、ユーザーがメソッドを介してオブジェクトをロードできるようにし、それをIQueryableでにIEnumerable<Product> LoadProducts(Predicate<Product> filter)変換します。Whereこれにより、他のIQueryableメソッドが非表示になりますが、フィルタリングの目的でのみ完全な柔軟性が得られます。

于 2012-05-04T15:01:09.313 に答える