实体框架POCO长期变更跟踪

Question

我正在使用.NET实体框架4.1，采用代码优先的方法来有效地解决以下问题，这里简化了。

• 有一个包含数万个条目的数据库表。
• 我的程序的几个用户需要能够
  • 在GridRow中查看（整个）表格，这意味着必须下载整个表格。
  • 修改任意随机行的值，更改频繁但不需要立即保留。预计不同的用户将修改不同的行，但这并非总是如此。允许进行一些更改，因为用户很可能会将相同的行更新为相同的值。
  • 有时添加新行。

听起来很简单。我最初的方法是使用长时间运行的DbContext实例。这个DbContext应该跟踪实体的更改，以便在调用SaveChanges()时，大部分的工作都是自动完成的。然而，许多人指出，从长远来看，这不是最佳解决方案，尤其是here。我还不确定我是否理解其中的原因，而且我也不知道我的方案中的工作单元是什么。用户选择何时持续更改，并且假设客户总是为了简单而获胜。同样重要的是要注意，未触摸的对象不会覆盖数据库中的任何数据。

另一种方法是手动跟踪变化或使用跟踪变化的对象，但是我不太熟悉这些技术，我欢迎在正确的方向上轻推。

解决此问题的正确方法是什么？

我知道这个问题有点过于愚蠢，但认为它更为根本。我对如何解决这类问题缺乏基本的了解。在我看来，长期生活DbContext是正确的方式，但知识渊博的人告诉我，这导致我混淆和不精确的问题。

EDIT1 另一个混淆点是Local对象上存在DbSet<>属性。它邀请我使用长时间运行的上下文，因为另一个用户发布了here。

Answer 1

长时间运行的上下文的问题是它不刷新数据 - 我更多地讨论了问题here。因此，如果您的用户打开列表并修改数据半小时，她就不知道更改。但是如果您的业务行为是WPF，则为WPF。

• 打开列表
• 执行任意数量的操作
• 触发保存更改

然后这整个是工作单元，你可以使用单个上下文实例。如果您有上次编辑获胜的场景，则在其他人删除当前用户编辑的记录之前，不应该遇到此问题。此外，在保存或取消更改后，您应该再次处理当前上下文和加载数据 - 这将确保您确实拥有下一个工作单元的最新数据。

Context提供了一些刷新数据的功能，但它只刷新以前加载的数据（没有关系），所以例如仍然会包含新的未保存记录。

也许您还可以阅读有关MS Sync框架和本地数据缓存的信息。

Answer 2

听起来像您的用户可能会在不确定的时间段内复制（缓存）数据。用户使用缓存数据的时间越长，他们在DbContext中与数据库连接断开连接的可能性就越大。我的猜测是EF不能很好地处理这个问题，你可能想要解决这个问题。 （例如 occaisionally connected 架构）。我希望实施可以解决你的许多问题。