实体框架是否有某种上下文缓存？
我们有两个 Web 应用程序，每个应用程序都为 EF 创建自己的数据上下文。当我对一个应用程序中的实体进行更改时，当我在 SQL Server Mangement Studio 中查看数据时，我会在页面和数据库中看到更改。但是，我没有立即看到其他应用程序中的更改。
两个应用程序都使用依赖项注入，并且两个应用程序都使用相同的业务层和数据层。因此，两个应用程序中的 UI 都通过一个公共控制器类（不要与 MVC 控制器混淆），并且控制器通过存储库来检索它正在检索的实体。因为它们是不同的应用程序，所以它们每个都有自己的实体框架数据上下文实例。
如果有某种缓存，我该如何关闭它？
提前致谢。
编辑 - 也许缓存发生在 EF 之上？清除浏览器缓存似乎无法解决问题。一段时间后，我会突然在另一个应用程序中看到记录的更新，但有一段时间没有多少刷新会显示更新。
We have two web applications and each one is creating it's own data context for EF. When I make changes to an entity in one app I see the changes on the page and in the database when I view the data in SQL Server Mangement Studio. However, I don't immediately see the changes in the other application.
Both apps use dependency injection and both applications use the same business layer and data layer. So the UI in both apps go through a common controller class (not to be confused with MVC controllers) and the controller goes through the repository for the entity it is retrieving. Because they are different apps they each have their own instance of entity framework data context.
If there is some kind of caching, how might I turn that off?
Thanks in advance.
EDIT - Maybe the caching is ocurring somewhere above EF? Clearing my browser cache doesn't seem to fix the issue. After some time goes by I will suddenly see the update to the record in the other app, but for a while no amount of refreshing will show me the updates.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果缓存发生在上下文中，则当您在当前 HTTP 请求结束时释放上下文时，缓存的值应该会消失。您确实有每个请求的上下文，对吧？
这里有一些 上下文生命周期最佳实践。
If the caching is occurring in the context, the cached values should go away when you dispose of the context at the end of the current HTTP request. You do have a per-request context, right?
Here's some context lifetime best practices.
是的，上下文缓存它们的结果。
您应该为每个查询创建一个新的上下文（或者实现类似 NHibernate 的 每个请求的会话)
Yes, contexts cache their results.
You should be creating a new context with every query (or implement something like NHibernate's Session-per-request)