LINQ to SQL - 存储过程如何与未提交的数据上下文更改交互？答案

【问题标题】：LINQ to SQL - How do stored procedures interact with unsubmited datacontext changes?LINQ to SQL - 存储过程如何与未提交的数据上下文更改交互？
【发布时间】：2010-08-06 15:02:52
【问题描述】：

这里有人问：

“Linq-To-Sql 启用调用 SP。如果这个 SP 执行更新/删除/插入，我需要在它之后 SubmitChanges() 吗？”

答案是：

“不，你不需要。代码将起作用。提交更改只涉及修改后的 LINQ to SQL 对象，而不涉及存储的过程。”

我想澄清一下：

（请原谅，我对 LINQ 比较陌生）

是的，但是存储过程不会绕过数据上下文对象并修改数据库本身吗？（而 linq 只修改 datacontext 对象，直到调用 datacontext.submitchanges 方法，然后修改数据库）

我可以让存储过程以某种方式修改我的 datacontext 对象吗？它已经这样做了吗？

我可以这样吗

如果我用 linq 调用 SP（并且我假设它直接修改数据库），
然后使用 linq 修改我的 datacontext 对象，并提交我对 datacontext 对象所做的更改，

我所做的两个不同的更改（一个是 SP，另一个是 Linq 到我的数据上下文）不会干扰吗？

我真正想要的是一种让我的存储过程修改我的数据上下文的方法。这可能吗？

我应该提到，我正在将一个网站从 SQL 转换为 LINQ，该网站主要包含存储过程，并尝试与哪些存储过程转换为 LINQ 以及哪些存储过程保留在 SQL 中并只是使用 SP 调用它们LINQ。

感谢您的帮助，-杰夫

【问题讨论】：

标签： linq-to-sql stored-procedures interaction submitchanges

【解决方案1】：

FWIW，我们的试金石测试是任何简单的“crud”类型 PROC，它插入/更新单个记录可以移动到 ORM

但是，我们倾向于将更高级的过程（批量更新或对性能高度敏感的过程）保持不变。

但是是的，您需要在调用依赖于 DataContext 中更改的数据状态的 Proc 之前调用 SubmitChanges()

可能不相关，如果您需要控制工作单元，请考虑将 TransactionScopes 放在您的代码周围？

【讨论】：

“如果您需要控制工作单元，请考虑放置 TransactionScopes”。或者只是手动打开一个连接，在其中启动一个事务并将该连接提供给DataContext 的构造函数之一。

【解决方案2】：

如果您通过存储过程更新记录，您加载（和跟踪）的对象可能会变得陈旧。如果您使用过时的对象调用 SubmitChanges，您将获得并发异常。您可以使用DataContext 上的Refresh 方法刷新过时的对象。

【讨论】：