这种情况实际上是对编码部分的误解。他们编写运行的第二部分查询（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 次，这可以使用延迟加载来减缓，而无需开发人员必须明确地告诉该框架，即他们无需担忧延迟加载的性能问题。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论