c# - 业务逻辑或 DAL 返回类型的 IEnumerable 与 IQueryable

Question

我知道以前有人问过这些问题，我将首先列出其中的一些(到目前为止我已经阅读过的):

• IEnumerable vs IQueryable
• List, IList, IEnumerable, IQueryable, ICollection, which is most flexible return type?
• Returning IEnumerable<T> vs. IQueryable<T>
• IEnumerable<T> as return type
• https://stackoverflow.com/questions/2712253/ienumerable-and-iqueryable
• Views with business logic vs code
• WPF IEnumerable<T> vs IQueryable<T> as DataSource
• IEnumerable<T> VS IList<T> VS IQueryable<T>
• What interface should my service return? IQueryable, IList, IEnumerable?
• Should I return IEnumerable<T> or IQueryable<T> from my DAL?

如您所见，SO 本身就有一些关于该主题的重要资源，但有一个问题/问题的一部分我仍然不确定是否已通读所有内容。

我主要关心 IEnumerable 与 IQueryable 的问题，更具体地说，是 DAL 与其消费者之间的耦合。

关于这两个界面，我发现了不同的意见，这两个界面都很棒。但是，我担心 DAL 返回 IQueryable 的含义。据我了解，IQueryable 建议/暗示幕后有一个 Linq 提供程序。这是第一个问题——如果 DAL 突然需要来自非 Linq 提供的来源的数据怎么办？以下是可行的，但它更像是一种 hack 吗？

public static IQueryable<Product> GetAll()
{
    // this function used to use a L2S context or similar to return data 
    // from a database, however, now it uses a non linq provider

    // simulate the non linq provider...
    List<Product> results = new List<Product> { new Product() };
    return results.AsQueryable();
}

所以我可以使用 AsQueryable() 扩展，尽管我不承认确切知道它的作用？我总是把 IQueryables 想象成底层表达式树，我们可以根据需要添加它，直到我们准备好执行我们的查询并获取结果。

我可以通过将函数的返回类型更改为 IEnumerable 来纠正此问题。然后我可以从函数返回 IQueryable，因为它继承了 IEnumerable，并且我可以保持延迟加载。我失去的是附加到查询表达式的能力:

var results = SomeClass.GetAll().Where(x => x.ProductTypeId == 5);

当返回 IQueryable 时，据我所知，这将简单地附加表达式。当返回 IEnumerable 时，尽管保留了延迟加载，但必须对表达式求值，以便将结果带到内存中并通过枚举来过滤掉不正确的 ProductTypeId。

其他人如何解决这个问题？

• 在 DAL 中提供更多功能 - GetAllByProductType、GetAllByStartDate...等

• 提供接受谓词的重载？即

  public static IEnumerable<Product> GetAll(Predicate<Product> predicate)
  {
  
      List<Product> results = new List<Product> { new Product() };
      return results.Where(x => predicate(x));
  }
  

最后一部分(抱歉，我知道，这个问题真的很长!)。

我发现 IEnumerable 是我检查过的所有问题中最受推荐的，但是延迟加载对数据上下文可用的要求又如何呢？据我了解，如果您的函数返回 IEnumerable，但您返回 IQueryable，则 IQueryable 依赖于底层数据上下文。因为这个阶段的结果实际上是一个表达式，没有任何内容被存入内存，所以您不能保证 DAL/函数的使用者将执行查询，也不能保证什么时候执行。那么我是否必须以某种方式保留结果派生的上下文实例？这就是工作单元模式发挥作用的方式/原因吗？

为清楚起见，问题摘要(搜索“?”...):

1. 如果使用 IQueryable 作为返回类型，您是否将 UI/业务逻辑与 Linq 提供程序紧密耦合？
2. 如果您突然需要从非 Linq 提供的源返回数据，使用 AsQueryable() 扩展是否是个好主意？
3. 任何人都有一个很好的链接来描述例如将标准列表转换为 AsQueryable 是如何工作的，它实际上做了什么？
4. 您如何处理业务逻辑向您的 DAL 提供的额外过滤要求？
5. 似乎 IEnumerable 和 IQueryable 的延迟加载都取决于维护底层提供程序，我应该使用工作单元模式还是其他方式来处理这个问题？

提前致谢!

Answer 1

1. 好吧，您并没有严格耦合到任何特定的提供者，但作为对它的重新措辞:您不能轻松地测试代码，因为每个提供者都有不同的支持功能(意思是: 对一个人有用的东西可能对另一个人不起作用 - 甚至像 .Single() )
2. 我不这么认为，如果您对不断变化的提供者有任何的疑问 - 请参阅上文
3. 它只是提供了一个使用.Compile() 的装饰包装器在任何 lambda 上，并改用 LINQ-to-Objects。请注意，LINQ-to-Objects 比任何其他提供程序都有更多支持，因此这不会成为问题 - 除了这意味着使用此方法的任何“模拟”都不会真正测试您的实际代码完全并且在很大程度上毫无意义(IMO)
4. 是的，棘手 - 见下文
5. 是的，棘手 - 见下文

就我个人而言，我更喜欢这里定义良好的 API，这些 API 采用已知参数并返回已加载 List<T>或 IList<T> (或类似的)结果；这为您提供了一个可测试/可模拟的 API，并且不会让您受到延迟执行(关闭连接 hell 等)的支配。这也意味着提供程序之间的任何差异都在内部处理到数据层的实现。它还更适合调用场景，例如 Web 服务等。

简而言之；在 IEnumerable<T> 之间做出选择和 IQueryable<T> ，我两者都不选择 - 选择使用 IList<T>或 List<T> .如果我需要额外的过滤，则:

1. 我将通过参数将其添加到现有 API，并在我的数据层内进行过滤
2. 我会接受超大数据返回，然后我需要在调用者处过滤掉