优化存储过程，以便 Linq2SQL 正确处理它们答案

【问题标题】：Optimizing Stored Procedures so they will be processed properly by Linq2SQL优化存储过程，以便 Linq2SQL 正确处理它们
【发布时间】：2010-11-24 09:59:38
【问题描述】：

在我工作的地方，我们需要通过存储过程作为通过代码访问数据的机制。我正在使用 LINQ2SQL 来最大程度地减少这种痛苦，以便我可以直接使用对象而不是 ADO.NET。我有一种情况，Linq2SQL 正在使用我的一个存储过程生成代码，其中存储过程调用的返回类型是 int。存储过程实际上返回一个数据集。经过一番研究，我发现这是因为 SQLClient 库无法正确解析存储过程以生成 Linq2SQL 用于创建对象图的预期元数据。我的问题是如何构造 sprocs（甚至是复杂的），以便您从 linq2sql 中获取对象图，或者换句话说，您应该避免在存储过程中使用哪些内容，这会导致 SQLClient 库不理解如何生成 linq2sql 使用的元数据以创建对象图？

【问题讨论】：

标签： linq-to-sql stored-procedures

【解决方案1】：

DamienG 在 Microsoft 的 LinqToSql 团队工作，我认为他的回答是正确的。

也就是说，他可能不会建议您远离 LinqToSql，我认为考虑该选项非常重要。

试图猜测存储过程的返回类型是非常困难的，LinqToSql 和其他人一样（对于 SQL Server）。也就是说，不使用存储过程有非常令人信服的理由：

Stored procedures are bad, m'kay?

如果您出于“安全原因”（我猜是您所处的情况）必须保护您的表免受开发人员的攻击，最好使用视图而不是存储过程来做到这一点。

如果您使用视图，那么 ORM 部门的选择比 LinqToSql 好得多。

在这方面，您使用 LinqToSql 遇到的主要问题是，对于 50 个或 500 个存储过程的小型数据库中的 5 个存储过程可以正常工作。您可以使用 O/R 设计器“覆盖”存储过程的返回类型，但是当存储过程或它们操作的表等发生更改时，您将遇到严重的同步问题。除非您从 O/R 设计器中删除存储过程，重新添加它，然后重新应用您的自定义覆盖，否则对存储过程的更改不会反映在 O/R 设计器中。如果您的项目与任何普通项目一样，表和存储过程经常更改，并且此同步问题很快就会成为一场噩梦，因为它完全是手动的，如果您未能正确执行，您将在运行时遇到非常奇怪的错误。

我强烈建议不要继续你现在的道路。

【讨论】：

我知道 Damien 是谁，我很重视他的 cmets。使用存储过程作为访问我们数据的机制的原因不是我个人可以控制的。这是一个架构决策，因此也是我们作为 .NET 开发人员所使用的内容。我提出这个问题的目的是我们决定使用 LINQ2SQL 作为我们选择的 O/R 映射工具，并且我想为我们的 DBA 组提供我能提供的任何信息，以便他们能够以这种方式编写存储过程因为我可以使用 LINQ2SQL 来使用它，而不必使用 ADO.NET。

【解决方案2】：

这实际上不是 LINQ to SQL 的限制，而是 SQL Server 的限制，当它包含临时表、游标或动态 SQL 时，它不能总是告诉客户端返回类型是什么而不实际运行它。

因为使用无效参数运行它可能会带来潜在的灾难性，所以它不会尝试。

您可以使用设计器手动设置它，或者如果完全可以使用无效数据运行存储过程（即它是纯粹被动的），那么您可以将 SET FMTOPT OFF 添加到存储过程的开始。

【讨论】：

在查看存储过程后，我们正在对存储过程顶部的变量进行一些选择以进行设置，但我们还有一个 Exec sprc 命令，该命令在存储过程的第 th 主体中返回一个输出参数也是。我猜想选择变量对于 Linq2Sql 来说应该不是问题，但它可能是 Exec 命令，它可能会把它扔掉。你知道这是否会导致 Linq2Sql 出现问题吗？另一个有趣的地方是 Exec sproc 有一个 out 参数，它在主 sproc 的主体中使用。最好的问候，迈克尔
避免 Exec sproc 将是一个好的开始 - 它很容易导致 SQL 注入并像动态 SQL 一样损害性能。如果没有看到 SP 本身，很难猜测它是如何被重写的。