返回 Enumerable.Empty<T>().AsQueryable() 是个坏主意？答案

【问题标题】：Returning Enumerable.Empty<T>().AsQueryable() a bad idea?返回 Enumerable.Empty<T>().AsQueryable() 是个坏主意？
【发布时间】：2011-06-02 22:13:18
【问题描述】：

这可能最好用一些代码来解释：

public IQueryable<DatabaseRecord> GetQueryableLinkedRecords()
{
    if(this.currentlyHeldIds.Count() == 0)
    {
        return Enumerable.Empty<DatabaseRecord>().AsQueryable();
    }
    else
    {
        return from r in this.DBContext.DatabaseRecords
               where this.currentlyHeldIds.Contains(r.Id)
               select r;
    }
}

如果没有 currentHeldId 可供查询，则没有理由再次实际查询数据库。如果 currentHeldIds 没有值，LINQ to SQL 仍将查询数据库。这种方法有什么问题吗？我意识到通常还有一些与返回 IQueryable 相关的其他问题，但除了这些论点之外，尝试像这样规避 db 调用有什么问题吗？

【问题讨论】：

标签： c# .net linq linq-to-sql iqueryable

【解决方案1】：

我认为你应该重新考虑你的函数实际上要做什么。如果您返回IQueryable<T>，则暗示调用者将存储结果查询，并在实际执行查询时收到最新结果。请记住：在这种情况下，数据库实际上不会被查询，直到在查询中调用 .ToList()、.ToArray()、foreach 等。

但是，如果您的目标是返回查询的当前状态，那么您的方法应该只返回 IList<T> 或类似的内容。然后，您可以返回一个空的 List<T>，或者在您构建的查询上调用 .ToList() 并返回它。

一般来说，我会尽量避免返回空的可查询对象，因为这会误导调用者他们实际得到的内容。

【讨论】：

好点，我没有考虑过延期执行。 currentlyHeldIds 的内容可能在方法被调用和迭代之间发生了变化。
非常好的点，绝对没有考虑它的延迟执行方面。

【解决方案2】：

对我来说似乎很好。如果从消费端看功能是相同的，那应该是非常好的。

【讨论】：