c# - 跨方法边界的 LINQ to SQL 规则

Question

为了保持我的代码更简洁，我经常尝试将 LINQ to SQL 中的部分数据访问代码分解为私有(private)子方法，就像使用普通的旧业务逻辑代码一样。让我举一个非常简单的例子:

public IEnumerable<Item> GetItemsFromRepository()
{
    var setA = from a in this.dataContext.TableA
               where /* criteria */
               select a.Prop;

    return DoSubquery(setA);
}

private IEnumerable<Item> DoSubQuery(IEnumerable<DateTimeOffset> set)
{
     return from item in set
            where /* criteria */
            select item;
}

我敢肯定，没有人会通过想象具有更深嵌套的更复杂的示例或使用集的结果来过滤其他查询来扩展想象力。

我的基本问题是:我看到一些显着的性能差异，甚至只是简单地在私有(private)方法中重新组织 LINQ to SQL 代码就会引发异常。谁能解释这些行为的规则，以便我可以就如何编写高效、干净的数据访问代码做出明智的决定？

我遇到的一些问题:

1) System.Linq.Table 实例到方法的传递何时导致查询执行？

2) 什么时候在另一个查询中使用 System.Linq.Table 会导致执行？

3) 可以将参数传递给方法的 System.Linq.Table 可以应用的操作类型(Take、First、Last、order by 等)是否有限制？

Answer 1

就 LINQ-to-SQL 而言，最重要的规则是:不要返回 IEnumerable<T>除非你必须——因为语义不清楚。除此之外还有两种思想流派:

• 如果你返回IQueryable<T> ，它是可组合的，意思是 where来自后面的查询被组合成一个 TSQL，但作为一个缺点，很难完全测试
• 否则返回List<T>或类似的，所以很明显，超出这一点的一切都是 LINQ-to-Objects

目前，您正在中间做一些事情:将其折叠为 LINQ-to-Objects(通过 IEnumerable<T> )，但不明显 - 并在中间保持连接打开(同样，这只是一个问题，因为它不明显)