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

Question

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

Answer 1

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

使用无效参数运行它可能是灾难性的，它不会尝试。

你可以使用设计师手动设置它，或者如果绝对没问题运行带有无效数据的存储过程（即它纯粹是被动的），那么你可以将SET FMTOPT OFF添加到启动存储过程。

Answer 2

DamienG在微软的LinqToSql团队工作，我的答案是正确的。

那就是说，他可能不会建议你远离LinqToSql，我认为考虑这个选项非常重要。

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

Stored procedures are bad, m'kay?

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

如果您正在使用视图，那么ORM部门的选项会比LinqToSql好很多。

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

我强烈建议不要继续沿着你的道路前进。