c# - EF 返回旧值

标签 c# entity-framework mvvm

我在我的桌面应用程序中使用 EF6 + WPF 和 MVVM 设计模式。我还使用 Autofac 作为 DI 容器。

我阅读了很多关于 EF 上下文生命周期管理的文章,我决定只为单个 View 模型实例设置一个 EF 上下文实例。我发现了几篇关于该方法的有趣文章,因此我认为这是管理 EF 上下文的唯一好方法。我使用 Autofac 来管理 EF 生命周期,所以每次我创建新的 View 模型时,都只会创建一个新的 EF 上下文。

当然,我遇到了一个问题。我的大多数 EF 查询都运行良好,但以下查询始终返回旧(缓存)值。每次按下“执行”按钮时我都会调用此查询,因此每个 View / View 模型都有很多次执行

this.context.someTable.Where(arg => arg.value == "value").Single();

我知道我总是可以用下面的代码重新加载实体

this.context.Entry(entity).Reload();

但对我来说这不是一个好的解决方案。我还知道,如果我处理当前上下文并在下一次查询之前重新创建,我将始终收到当前值。但是这种方法与每个 View 模型一个上下文的方法相冲突。

我应该修复/更改什么以避免 EF 缓存问题并仍然具有良好的性能。

最佳答案

你不应该保留上下文

我建议您放弃单一的共享上下文。我最近为一个大型 WPF 应用程序做了这个。 EF 上下文被设计为一个工作单元,您应该使用它然后调用 .Dispose()。如果您需要急切地读取关系属性,则应使用 .Include() 提示。您应该在 using block 中构建您的上下文,这样您就知道在哪里丢失了范围,并确保上下文被释放。

您会发现 EF 的性能实际上会降低,因为它需要引用其内部缓存和状态。我发现如果使用共享上下文,批量数据插入模式会恶化。 EF 的性能不如 RDBMS。

正如您所体验的那样,您可以保留上下文并从缓存的实体中受益,但如果这变得很痛苦,那么由于您的系统的性质和用户的要求,您将不再真正从缓存中受益。您的支持 RDBMS 应该足够快。一旦以任何方式缓存(包括 EF 二级缓存和 ASP.NET 输出缓存),您立即需要计划如何使缓存的实体过期。这为您的编码人员增加了更多工作,并为您的系统提供了惊人的新失败方式。

例如,考虑 EF 的一个好处是关系属性的自动解析。您可以无缝地跨越数据图,直到您遇到缓存和陈旧的实体。在这种情况下,很难在检索此类实体之前使缓存过期。

但是如果你必须在更新时重新加载

如果您真的不想将架构更改为 Microsoft 推荐/预期的方式。我建议您跟踪所有打开的上下文(在构建时添加到静态集合,在处理时删除,使用终结器模式仔细检查,以及在处理时抑制终结器),并在保存管道中实现一些通用代码(有几种方法这样做)尝试在所有打开的上下文中重新加载实体。这是一种使 EF 实体缓存过期的主动方式。这可能会影响较大集合的性能,但您可以处理白名单或黑名单实体,而不是处理所有保存的实体。

就个人而言,我很高兴我做出了改变(重组为短期上下文),从长远来看,在代码可维护性和系统稳定性方面有巨大的好处。

关于c# - EF 返回旧值,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28042161/

相关文章:

具有泛型类型约束的 C# 多态性

c# - Entity Framework 原始 SQL 查询选择未知列(未知返回类型)

c# - 使用 Fody [ImplementPropertyChanged] 时出错

c# - 绑定(bind)命令丢失

c# - 如何在不使用 transform.Rotate 的情况下在其本地或世界轴上旋转具有第二个四元数的四元数?

c# - MSSQL Linux 服务器问题 : SQL Server only supports SAFE assemblies

c# - 在 List<T> 中查找 IEnumerable<T> 时,GetGenericTypeDefinition 返回 false

c# - 带 Action 的 ReaderWriterLockSlim 扩展

c# - IQueryable for entities .Where(属性在本地数组中)

c# - 尽管我们不能在 xaml 中应用它们,但是否有任何理由使用通用 View 模型?