LINQ-to-Entities确实是依赖于之前的查询来返回不同的结果吗？

Stu Smith最近在博客贴出文章声称：“LINQ-to-Entities依赖于你之前执行的查询来返回不同的结果 ”。如果情况属实，这样会使得使用Entity Framework比原来还要困难。我们和ADO.NET团队的Elisa Flasko交流，找出究竟发生什么事情？

这种情况实际上是对编码部分的误解。他们编写运行的第二部分查询（var order部分），实际上是一个LINQ to Object查询，而非LINQ to Entities (或 LINQ to SQL)查询。该LINQ to Object查询是查询之前由第一部分查询（var alice部分）导入到内存的数据，。

现在产生不同结果的原因，就是LINQ to SQL支持延迟加载，而Entity Framework第一个版本并不支持。所以如果你查看第一部分查询，该代码仅把Customer实体引入到内存（在LINQ to SQL和LINQ to Entities中的确如此）。然而，在第二部分查询（Orders）中，代码尝试访问相关的Orders实体。现在延迟加载接着第二次访问数据库来获取这些信息，然而在Entity Framework中的显式加载意味着，他要对数据库“不可思议地”进行额外访问。由于Orders不在内存中，在你对LINQ to Entities查询结果执行LINQ to Objects查询的时候，Orders则不可用。然而，在foreach循环（代码特别调用了data.Orders-访问该上下文并在数据库中查询所有Orders）之后，该Orders就在内存中，因此LINQ to Objects就可基于它们来查询。

也就是说，我们让你能够在Entity Framework的第二版中开启延迟加载，然而，它在默认情况下仍将关闭。理由是为了确保开发者不会意外地遇上性能问题的情况，即数据库被访问N+1次，这可以使用延迟加载来减缓，而无需开发人员必须明确地告诉该框架，即他们无需担忧延迟加载的性能问题。

所以这是一个重要的设计问题抑或只是一个培训问题？

查看英文原文：Does LINQ-to-Entities really return different results depending on previous queries?