我想澄清一些事情，因为似乎相互矛盾的反应(主要围绕IEnumerable)。

IQueryable扩展了IEnumerable接口。(你可以发送一个IQueryable给一个期望IEnumerable而没有错误的对象。)

(2) IQueryable和IEnumerable LINQ在迭代结果集时都尝试延迟加载。(注意，可以在每种类型的接口扩展方法中看到实现。)

换句话说，IEnumerables不是独占的“内存中”。IQueryables并不总是在数据库上执行。IEnumerable必须将数据加载到内存中(一旦检索到，可能是惰性的)，因为它没有抽象数据提供程序。IQueryables依赖于抽象提供者(如LINQ-to-SQL)，尽管这也可以是. net内存中的提供者。

样例用例

(a)从EF上下文检索IQueryable记录列表。(内存中没有记录。)

(b)将IQueryable传递给模型为IEnumerable的视图。(有效。IQueryable扩展IEnumerable。)

(c)在视图中遍历并访问数据集的记录、子实体和属性。(可能会导致异常!)

可能的问题

IEnumerable尝试延迟加载，你的数据上下文过期了。由于提供程序不再可用而引发异常。

(2)实体框架实体代理已启用(默认)，并且您尝试访问具有过期数据上下文的相关(虚拟)对象。同(1)。

(3)多活动结果集(MARS)。如果你在foreach(var record in resultSet)块中遍历IEnumerable，同时尝试访问record. childentity。childProperty，由于数据集和关系实体的惰性加载，您可能最终会得到MARS。如果在连接字符串中未启用该选项，则会导致异常。

解决方案

我发现在连接字符串中启用MARS工作不可靠。我建议你避免MARS，除非它被很好地理解和明确地渴望。

执行查询并通过调用resultList = resultSet.ToList()来存储结果，这似乎是确保实体位于内存中的最直接的方法。

在访问相关实体的情况下，可能仍然需要数据上下文。或者，您可以禁用实体代理，并显式地从DbSet中包含相关实体。

“IEnumerable”和“IQueryable”之间的主要区别在于在哪里执行筛选逻辑。一个在客户端(内存中)执行，另一个在数据库中执行。

例如，我们可以考虑一个例子，我们的数据库中有一个用户的10,000条记录，假设只有900个是活动用户，所以在这种情况下，如果我们使用“IEnumerable”，那么首先它将所有10,000条记录加载到内存中，然后应用IsActive筛选器，最终返回900个活动用户。

而另一方面，在同样的情况下，如果我们使用“IQueryable”，它将直接应用数据库上的IsActive过滤器，直接从那里将返回900个活跃用户。

我想澄清一些事情，因为似乎相互矛盾的反应(主要围绕IEnumerable)。

IQueryable扩展了IEnumerable接口。(你可以发送一个IQueryable给一个期望IEnumerable而没有错误的对象。)

(2) IQueryable和IEnumerable LINQ在迭代结果集时都尝试延迟加载。(注意，可以在每种类型的接口扩展方法中看到实现。)

换句话说，IEnumerables不是独占的“内存中”。IQueryables并不总是在数据库上执行。IEnumerable必须将数据加载到内存中(一旦检索到，可能是惰性的)，因为它没有抽象数据提供程序。IQueryables依赖于抽象提供者(如LINQ-to-SQL)，尽管这也可以是. net内存中的提供者。

样例用例

(a)从EF上下文检索IQueryable记录列表。(内存中没有记录。)

(b)将IQueryable传递给模型为IEnumerable的视图。(有效。IQueryable扩展IEnumerable。)

(c)在视图中遍历并访问数据集的记录、子实体和属性。(可能会导致异常!)

可能的问题

IEnumerable尝试延迟加载，你的数据上下文过期了。由于提供程序不再可用而引发异常。

(2)实体框架实体代理已启用(默认)，并且您尝试访问具有过期数据上下文的相关(虚拟)对象。同(1)。

(3)多活动结果集(MARS)。如果你在foreach(var record in resultSet)块中遍历IEnumerable，同时尝试访问record. childentity。childProperty，由于数据集和关系实体的惰性加载，您可能最终会得到MARS。如果在连接字符串中未启用该选项，则会导致异常。

解决方案

我发现在连接字符串中启用MARS工作不可靠。我建议你避免MARS，除非它被很好地理解和明确地渴望。

执行查询并通过调用resultList = resultSet.ToList()来存储结果，这似乎是确保实体位于内存中的最直接的方法。

在访问相关实体的情况下，可能仍然需要数据上下文。或者，您可以禁用实体代理，并显式地从DbSet中包含相关实体。

都能让你延期执行，没错。

至于哪个是首选的，这取决于您的底层数据源是什么。

返回一个IEnumerable将自动强制运行时使用LINQ to Objects来查询您的集合。

返回一个IQueryable(顺便说一下，它实现了IEnumerable)提供了额外的功能，可以将您的查询转换为可能在底层源上执行得更好的查询(LINQ to SQL, LINQ to XML，等等)。

一般来说，您希望保留查询的原始静态类型，直到有必要。

出于这个原因，你可以将你的变量定义为'var'，而不是IQueryable<>或IEnumerable<>，你会知道你没有改变类型。

如果您开始使用IQueryable<>，通常希望将其保留为IQueryable<>，直到有一些令人信服的理由更改它。这样做的原因是您希望为查询处理器提供尽可能多的信息。例如，如果你只打算使用10个结果(你已经调用Take(10))，那么你想让SQL Server知道这一点，这样它就可以优化它的查询计划，只向你发送你将使用的数据。

A compelling reason to change the type from IQueryable<> to IEnumerable<> might be that you are calling some extension function that the implementation of IQueryable<> in your particular object either cannot handle or handles inefficiently. In that case, you might wish to convert the type to IEnumerable<> (by assigning to a variable of type IEnumerable<> or by using the AsEnumerable extension method for example) so that the extension functions you call end up being the ones in the Enumerable class instead of the Queryable class.

上面的答案很好，但它没有提到解释两个接口“如何”不同的表达式树。基本上，有两组相同的LINQ扩展。Where()， Sum()， Count()， FirstOrDefault()等都有两个版本:一个接受函数，一个接受表达式。

IEnumerable版本签名为:Where(Func<Customer, bool> predicate) IQueryable版本签名是:Where(表达式<Func<Customer, bool>>谓词)

你可能在没有意识到的情况下使用了这两个函数，因为它们使用相同的语法调用:

例如，Where(x => x.City == "<City>")对IEnumerable和IQueryable都有效

当在IEnumerable集合上使用Where()时，编译器将一个编译后的函数传递给Where() 当在IQueryable集合上使用Where()时，编译器将表达式树传递给Where()。表达式树类似于反射系统，但用于代码。编译器将代码转换为数据结构，该结构以易于理解的格式描述代码的功能。

为什么要用这个表达式树呢?我只想让Where()过滤我的数据。 主要原因是EF和Linq2SQL orm都可以将表达式树直接转换为SQL，这样您的代码将执行得更快。

哦，这听起来像一个免费的性能提升，我应该在这种情况下使用AsQueryable()吗? 不，IQueryable只有在底层数据提供程序可以使用它时才有用。将常规列表转换为IQueryable不会给你带来任何好处。