这类情形实践上是对编码部分的曲解。他们编写运转的第二部分查询(varorder部分),实践上是一个LINQtoObject查询,而非LINQtoEntities(或LINQtoSQL)查询。该LINQtoObject查询是查询之前由第一部分查询(varalice部分)导进到内存的数据,。
如今发生分歧了局的缘故原由,就是LINQtoSQL撑持提早加载,而EntityFramework第一个版本其实不撑持。以是假如你检察第一部分查询,该代码仅把Customer实体引进到内存(在LINQtoSQL和LINQtoEntities中切实其实云云)。但是,在第二部分查询(Orders)中,代码实验会见相干的Orders实体。如今提早加载接着第二次会见数据库来猎取这些信息,但是在EntityFramework中的显式加载意味着,他要对数据库“难以想象地”举行分外会见。因为Orders不在内存中,在你对LINQtoEntities查询了局实行LINQtoObjects查询的时分,Orders则不成用。但是,在foreach轮回(代码出格挪用了data.Orders-会见该高低文并在数据库中查询一切Orders)以后,该Orders就在内存中,因而LINQtoObjects便可基于它们来查询。
也就是说,我们让你可以在EntityFramework的第二版中开启提早加载,但是,它在默许情形下仍将封闭。来由是为了确保开辟者不会心外埠赶上功能成绩的情形,即数据库被会见N+1次,这可使用提早加载来减缓,而无需开辟职员必需明白地告知该框架,即他们无需担心提早加载的功能成绩。
欢迎光临 仓酷云 (http://ckuyun.com/) | Powered by Discuz! X3.2 |