我正在使用 .NET Entity Framework 4.1 和代码优先方法来有效解决以下问题，此处已简化。
- 有一个包含数万个条目的数据库表。
- 我的程序的几个用户需要能够
- 在 GridRow 中查看(整个)表格，这意味着必须下载整个表格。
- 修改任何随机行的值，更改很频繁但不需要立即持久化。预计不同的用户将修改不同的行，但这并不总是如此。允许丢失一些更改，因为用户很可能会将相同的行更新为相同的值。
- 有时会添加新行。
听起来很简单。我最初的方法是使用长时间运行的 DbContext实例。这个DbContext应该跟踪实体的变化，所以当SaveChanges()被调用时，大部分跑腿工作都是自动完成的。然而，许多人指出这不是从长远来看的最佳解决方案，特别是 here .我仍然不确定我是否理解原因，而且我也看不到我的场景中的工作单元。用户自己选择何时保留更改，假设客户端总是以简单为赢。还需要注意的是，未被触及的对象不会覆盖数据库中的任何数据。
另一种方法是手动跟踪更改或使用为我跟踪更改的对象，但我不太熟悉此类技术，我欢迎向正确的方向插入。
解决这个问题的正确方法是什么？
我知道这个问题有点空泛，但我认为它更基本。我对如何解决这类问题缺乏基本的了解。在我看来长寿DbContext是正确的方法，但有知识的人告诉我不是这样，这导致我感到困惑和不精确的问题。
编辑1
另一个混淆点是 Local 的存在。 DbSet<> 上的属性(property)目的。它邀请我使用长时间运行的上下文，因为另一位用户已发布 here .
最佳答案
长时间运行上下文的问题是它不刷新数据 - 我更多地讨论了问题 here .因此，如果您的用户打开列表并修改数据半小时，她不知道更改。但在 WPF 的情况下，如果您的业务行为是:
- 打开列表
- 想做多少就做多少
- 触发保存更改
那么这就是一个工作单元，您可以为此使用单个上下文实例。如果您遇到最后一次编辑获胜的情况，那么在其他人删除当前用户编辑的记录之前，您不应该对此有任何问题。此外，在保存或取消更改后，您应该处理当前上下文并再次加载数据 - 这将确保您真正拥有用于下一个工作单元的新数据。
Context 提供了一些刷新数据的功能，但它只刷新以前加载的数据(没有关系)，因此例如新的未保存的记录仍将包括在内。
也许您还可以阅读有关 MS Sync 框架和本地数据缓存的内容。
关于c# - Entity Framework POCO 长期变更跟踪，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6008932/