我找不到类似的东西，所以我不得不问：
我使用LINQ to SQL，一切都很好，直到我开始使用存储过程来更新数据库条目。 （我的存储过程类似于更新groupid x的所有条目） 更新运行正常，数据库中的值更改。但DataContext忽略了这一变化。
我不得不说数据上下文是一个单例，我知道这不是常见的方法，但我有不同的理由为什么我必须这样做。
所以
db.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues);
无济于事。
为什么他不知道db的变化？
答案 0 :(得分：2)
因为datacontext正在缓存值。这是一篇关于如何clear the cache的文章。但是现在你遇到了一个知道何时清除它的通知系统的问题。
Microsoft建议数据上下文仅用于单个工作单元。挂在它上面作为单身可能并不是一个好主意。
答案 1 :(得分：2)
你要做的事情与LinqToSql的工作原理非常相似。
使用长期存在的DataContext非常难以正确执行，尤其是当您需要调用存储过程时，LinqToSql无法轻松跟踪数据更改。
通常会自动跟踪通过DataContext进行的更改，因此DataContext可以正确管理其缓存并跟踪从该DataContext对数据库所做的更改。但情况并非总是如此。 DataContext不（并且不能轻易）理解存储过程正在做什么，因此它不知道如何保持其缓存正确。此时，在调用存储过程之后，最好的选择是去除DataContext并创建一个新的DataContext。这有效地消除了您的缓存，这可能会或可能不会成为显着的性能损失，但数据完整性应该是您的主要关注点。
如果您的Singleton DataContext不是修改数据库的唯一内容（例如，您的数据库可能被以下内容修改：触发器，批处理，其他应用程序等），您的DataContext也可能包含不准确的数据。缓存，这是拥有一个短暂的DataContext的另一个原因。
所以，虽然你可以成功使用长寿的Singleton DataContext，但你将在整个过程中与系统作斗争，系统最终可能获胜。
您必须决定：数据完整性有多重要？