1

例如，如果我与 dlinq 竞争

var custq = data.StoreDBHelper.DataContext.Customers as IEnumerable <Data.SO.Customer>;

我认为与跑步没有太大区别：

var custq = data.StoreDBHelper.DataContext.Customers as IQueryable <Data.SO.Customer>;

因为，IQueryable 继承自 IEnumerable。

但是我发现了以下内容，如果您调用： custq.Sum() 那么程序将在您调用 .toList() 时处理它，您使用“as IEnumerable”，因为程序上的内存提升到同一级别，当我尝试过，custq.ToList.Sum() 但不在“as IQueryable”上（因为问题随后在 sql server 上运行）并且不影响程序的内存使用情况。

我的问题很简单，你不应该在 Dlinq 上使用“as IEnumerable”吗？但是“作为 IQueryable”作为一般规则？我知道，如果您正在运行标准迭代，它会在“as IEnumerable”和“as IQueryable”之间得到相同的结果。

但是，仅仅是 where 语句中的汇总函数和委托表达式会有所不同 - 还是如果您使用“as IQueryable”，您通常会获得更好的性能？（用于 DLinq 实体上的标准迭代和过滤功能）

谢谢 ！

4

1 回答 1

1

好吧，取决于你想做什么......将其转换为 IEnumerable 将返回一个你可以枚举的对象......仅此而已。所以是的，如果您在 IEnumerable 上调用 Count，那么您将枚举列表（因此您实际上执行了 Select 查询）并计算每次迭代。

另一方面，如果您保留一个 IQueryable，那么您可以枚举它，但您也可以执行数据库操作，如 Were、OrderBy 或 count。然后这将延迟查询的执行并最终在运行之前对其进行修改。

对可枚举调用 OrderBy 浏览所有结果并在内存中对它们进行排序。在可查询对象上调用 OrderBy 只需在 SQL 末尾添加 ORDER BY 并让数据库进行排序。

一般来说，最好将其保留为 IQueryable，是的...除非您想通过实际浏览它们来计算它们（而不是执行 SELECT COUNT(*)...）

于 2013-08-16T09:31:02.730 回答