在服务层方法中将 IQueryable 作为参数传递是一种好习惯吗？

Question

我有一个具有 3 层 UI、Service Layer 和 Repository 的 ASP.NET 应用程序。

我必须对数据库中的产品实施搜索功能。 ProductRepository 是我的 repository 类，从数据库中获取所有 products 的方法的签名是：

IQueryable<Product> GetAllProducts();

因此从我的服务层我使用：

IProductRepository _ProductRepository = new ProductRepository(); 

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

如果我想过滤IQueryable<Product> products，例如选择那些 price > 100 的产品或只选择 color = "yellow" 的产品。

所以我想知道，而不是在ProductRepository 中创建方法，例如：

IQueryable<Product> GetAllProductsByColor(int colorId)

我想知道在我的服务层中创建一组接受IQueryable<Product>作为参数并直接在那里执行过滤的方法是否是一个好习惯：

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

其中Dictionary<string, string> 表示具有 (propertyName, value) 的集合。

此解决方案的优点是，如果我必须应用多个过滤器，我只需传递已过滤的 IQueryable<Product>，而不是每次都获取过滤后的产品集之间的交集。

这是一种好习惯（只要我保持上下文打开）还是多层架构模式不“允许”？

Answer 1

我会说这取决于提供 IQueryable 实现的内容。在大多数情况下，您冒着允许 IQueryable 的用户执行以下任一操作的风险：1) 过滤未编入索引的字段（因此，当您有大表时，如果有的话，数据库层会存储数据库层），或者 2) 执行任意 IQueryable对数据库造成巨大负载的操作（例如 GroupBy、Join 等）。

假设您同意 1，为了防止 2) 我通常允许用户通过 IEnumerable<Product> LoadProducts(Predicate<Product> filter) 方法加载对象，然后我将其转换为 IQueryable 上的 Where；这隐藏了其他 IQueryable 方法，但允许完全灵活地仅用于过滤目的。