为什么使用AsQueryable（）而不是List（）？

我正在使用entity framework和LINQ的数据访问使用存储库模式作为实施非testing存储库的基础。当调用返回N个logging而不是List <T>时，我看到的大多数示例都返回AsQueryable（）。这样做的好处是什么？

AsQueryable只是创build一个查询，获取列表所需的说明。您可以稍后对查询进行更改，例如将新的Where子句添加到数据库级别。

AsList返回一个包含内存中所有项目的实际列表。如果你添加一个新的地方，你不会得到数据库提供的快速过滤。相反，您可以获取列表中的所有信息，然后在应用程序中筛选出您不需要的内容。

所以基本上是等到最后才做出承诺之前。

返回IQueryable<T>的好处是，执行是defferer，直到你真正开始枚举结果，你可以用其他查询编写查询，仍然可以得到服务器端执行。

问题是，你不能控制数据库上下文的生命周期在这个方法中 – 你需要一个开放的上下文，并且必须确保它保持打开直到查询被执行。然后你必须确保上下文将被处置。如果将结果作为List<T> ， T[]或类似的东西返回，那么您松散地执行组合查询的执行和服务器端执行，但是您可以控制数据库上下文的生存期。

当然，最合适的取决于实际的要求。这是没有一个真相的另一个问题。

AsQueryable是IEnumerable<T>的扩展方法，可以做两件事情：

如果IEnumerable<T>实现IQueryable<T>只是施放，什么都不做。
否则，创build一个“假的” IEnumerable<T> （ EnumerableQuery<T> ），它实现了编译lambdaexpression式并调用Enumerable扩展方法的每个方法。

所以在大多数情况下，使用AsQueryable是没有用的，除非你被迫将一个IQueryable传递给一个方法，而你有一个IEnumerable，这是一个黑客攻击。

注意：AsQueryable是一个黑客，IQueryable当然不是！

返回IQueryable<T>将推迟查询的执行，直到实际使用它的结果为止。在此之前，您还可以在IQueryable<T>上执行额外的数据库查询操作; 在List您只能使用低效的内存操作。