EF构建EntityCollection，但我（认为我）想要IQueryable [英] EF builds EntityCollection, but I (think I) want IQueryable

问题描述

我有一个实体 A ，具有简单的导航属性 B 。对于任何给定的 A 的实例，我们预期几个相关的千个实例 B 。

没有任何情况，我打电话给：

  foreach（AB中的var x） ..} 
  

相反，我只是有兴趣做聚合操作例如

  var statY = ABWhere（o => o.Property ==Y）; 
 var statZ = A.B.Where（o => o.CreateDate> DateTime.Now.AddDays（-1））; 
  

据我所知，EF会实例化数千个对B的引用，并在内存中执行这些操作。这是因为导航属性使用EntityCollection。相反，我希望它可以在SQL级别执行这些查询。

我目前的预期是，导航属性可能不是正确的方法。我没有附加到EF，所以我对其他方法开放。但是如果可能的话，我会非常有兴趣知道在EF下正确的方法。

（我使用的是EF4。）

$ b $

所以我的例子现在是：

  var statY = ABCreateSourceQuery（）。其中​​（o => o.Property ==Y）; 
 var statZ = A.B.CreateSourceQuery（）。其中​​（o => o.CreateDate> DateTime.Now.AddDays（-1））; 
  

I have an entity A with a simple navigation property B. For any given instance of A, we expect several related thousand instances of B.

There is no case where I call something like:

foreach(var x in A.B) { ... }

Instead, I'm only interested in doing aggregate operations such as

var statY = A.B.Where(o => o.Property == "Y");
var statZ = A.B.Where(o => o.CreateDate > DateTime.Now.AddDays(-1));

As far as I can tell, EF instantiates thousands of references to B and does these operations in memory. This is because navigation properties use EntityCollection. Instead, I'd like it to perform these queries at the SQL level if possible.

My current hunch is that Navigation Properties may not be the right way to go. I'm not attached to EF, so I am open to other approaches. But I'd be very interested to know the right way to do this under EF if possible.

(I'm using EF4.)

解决方案

CreateSourceQuery seems to do the trick.

So my examples would now be:

var statY = A.B.CreateSourceQuery().Where(o => o.Property == "Y");
var statZ = A.B.CreateSourceQuery().Where(o => o.CreateDate > DateTime.Now.AddDays(-1));

这篇关于EF构建EntityCollection，但我（认为我）想要IQueryable的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！