IQueryable有什么大不了的？

Question

我见过很多人在谈论IQueryable，我还没有完全理解所有的嗡嗡声。我总是使用通用的List来发现它们非常丰富，可以“查询”它们并与它们一起工作，甚至可以针对它们运行LINQ查询。

我想知道是否有充分的理由开始在我的项目中考虑不同的默认集合。

Answer 1

IQueryable接口允许您定义针对远程LINQ提供程序（通常针对数据库，但不一定是）的查询部分，并且执行延迟执行。

E.g.您的数据库层可以通过在查询中添加.Where(x => x.......)子句来定义一些限制（例如基于权限，安全性等）。但是这还没有被执行 - 例如你是而不是检索符合该标准的150'000行。

相反，您将IQueryable接口传递到下一级别的业务层，您可能会在其中添加额外的需求和查询的where子句 - 再次，您还没有执行任何操作，您也不会抛出您检索的150'000行中有80,000个 - 您只是定义了其他查询条件。

而UI层可能做同样的事情，例如，基于用户在表单或其他东西上的输入。

奇妙之处在于，您将通过所有图层传递接口，为其添加额外的关键 - 但在实际强制之前它不会被执行/评估。这也意味着你不会不必要地选择和检索后来丢弃的大量数据。

你不能用传统的静态列表来做到这一点 - 你必须选择数据，以后可能会丢弃大量的数据 - 毕竟你有一个静态列表。

Answer 2

IQueryable允许您使用LINQ进行查询，就像LINQ to Object查询一样，查询实际上是“编译”并在别处运行。

最常见的实现工作对数据库。如果使用List<T>和LINQ to Objects，则将整个“表”数据加载到内存中，然后针对它运行查询。

通过使用IQueryable<T>，LINQ提供可以将您的LINQ语句“翻译”为实际的SQL代码，并在数据库上运行它。结果可以返回给你并枚举。

这非常有效得多，特别是在您使用N层系统时。

Answer 3

针对IEnumerable<T>的LINQ查询产生委托（方法），调用时执行所述的查询。

针对IQueryable<T>的LINQ查询产生expression trees，这是一个代表生成查询的代码的数据结构。 LINQ提供程序（如LINQ to SQL）解释这些数据结构，在目标平台（本例中为T-SQL）上生成相同的查询。

对于编译器如何解释对IQueryable<T>查询语法示例，请参阅我的回答这个问题：

Building Dynamic LINQ Queries based on Combobox Value