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

Question

我知道以前有人问过这些问题，我将首先列出其中的一些问题（到目前为止我读过的问题）：

• IEnumerable 与 IQueryable
• List、IList、IEnumerable、IQueryable、ICollection，哪个最灵活返回类型？
• 返回 IEnumerable与 IQueryable
• IEnumerable相比作为返回类型
• https://stackoverflow.com/questions/2712253/ienumerable-and-iqueryable
• 具有业务逻辑的视图与代码
• WPF IEnumerable;与 IQueryable比较作为数据源
• IEnumerable; VS IListVS IQueryable
• 我的服务应该使用什么接口返回？ IQueryable、IList、IEnumerable？
• 我应该返回 IEnumerable< ；T>或IQueryable正如您所看到的，仅就该主题而言，就有一些很棒的资源，但是有一个问题/问题的

一部分我仍然不确定是否已阅读完所有这些内容。

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

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

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; GetAll(谓词<产品>谓词)
  {
  
      列表<产品>结果=新列表<产品>; { 新产品() };
      返回结果。Where(x => 谓词(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. 它只是提供了一个装饰包装器，使用任何 lambda 上的 .Compile() ，并使用 LINQ-to-Objects 代替。注意 LINQ-to-Objects 比任何其他提供程序都拥有更多支持，因此这不会成为问题 - 只不过这意味着使用此方法的任何“模拟”都不会真正测试您的实际代码根本而且基本上毫无意义（IMO）
4. 是的，棘手 - 见下文
5. 是的，棘手 - 见下文就

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

。如果在 IEnumerable 和 IQueryable 之间进行选择，我两者都不选择 - 选择使用 IList 或 列表。如果我需要额外的过滤，那么：

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