决定使用 LINQ to SQL 与 StoredProcs

Question

在开发应用程序时，我通常会使用存储过程来包含CRUD逻辑，以提高性能和可维护性。但在尝试 LINQ to SQL 后，我想知道使用对存储过程编译的 LINQ-to-SQL 查询是否有助于提高性能？

Answer 1

LINQ to SQL 不会提高性能，因为您将通过线路将每个 CRUD 操作作为字符串发送。

使用存储过程的性能仍然会更好，但像 Linq to SQL 这样的 ORM 通常可以缩短开发时间。

Answer 2

根据我的经验，我可以对性能进行如下排名：

1. 存储过程
2. 本机查询（使用 DBCommand）
3. Linq to 实体（编译查询，EF4）
4. Linq to SQL（编译）
5. Linq to 实体（未编译 EF4）
6. Linq to SQL

7. ESQL< /p>

   2,3,4 可能会根据查询的性质改变它们的顺序，但一般来说，原始 sql 查询的执行速度会更快。

Answer 3

根据您对 DevSlick 和 a1ex07 的评论，您似乎对 LINQ 存在根本性的误解。为了让 LINQ 查询允许链接，

var activePeople = peopleList.Where(o => o.Active).OrderBy(o => o.Ordering).Select(o => o.Name);

LINQ 查询的执行必须是 延迟直到枚举：

foreach(var person in activePeople)
{
   //If this is LINQ-to-SQL, the query to peopleList has waited until now to request anything from the database
}

这意味着查询.Where(o => o.Active).OrderBy(o => o.Ordering)。 Select(o => o.Name) 在此之前您的计算机实际上也不会解释。如果您运行相同的查询 100 次，这意味着计算机必须重新解释该查询 100 次。对于 LINQ-to-SQL，这意味着在每次将 SQL 发送到数据库之前将查询转换为 SQL 100 次，即使每次 SQL 都完全相同。

提前编译查询会导致它仅生成一次 SQL，并在每次调用查询时使用该 SQL。这与存储过程无关 - 您可以像编译任何其他查询一样将查询编译为存储过程。询问“哪个提供更好的性能”是没有意义的，因为它们并不相互排斥。

尽管编译查询听起来像是一件好事，但实际上解释 LINQ 查询（通常称为“评估表达式树”）与实际对数据库执行 SQL 相比只需要很少的时间，因此您对于编译查询来说几乎没有什么好处。同时，编译查询的语法是atrocious：

static readonly Func<AdventureWorksEntities, Decimal, IQueryable<SalesOrderHeader>> s_compiledQuery2 = 
    CompiledQuery.Compile<AdventureWorksEntities, Decimal, IQueryable<SalesOrderHeader>>(
        (ctx, total) => from order in ctx.SalesOrderHeaders
                        where order.TotalDue >= total
                        select order);

var orders = s_compiledQuery2.Invoke(context, totalDue);

为此出于原因，通常建议不要编译 LINQ-to-SQL 查询，因为代码噪音与效益的比率非常糟糕。