0

我有一个具有 3 层UI、服务层和存储库的 ASP.NET 应用程序。

我必须在数据库中的产品上实现搜索功能。 ProductRepository是我的存储库类，从数据库中获取所有产品的方法的签名是：

IQueryable<Product> GetAllProducts();

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

IProductRepository _ProductRepository = new ProductRepository(); 

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

如果我想过滤IQueryable<Product> products，例如使用价格 > 100的产品或仅使用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 等）。

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

于 2012-05-04T15:01:09.313 回答