实体框架 POCO 长期变更跟踪
我使用 .NET 实体框架 4.1 和代码优先方法来有效解决以下问题，这里进行了简化。
- 有一个包含数万条条目的数据库表。
- 我的程序的几个用户需要能够
- 在 GridRow 中查看（整个）表格，这意味着必须下载整个表格。
- 修改任意随机行的值，更改很频繁，但不需要立即保留。预计不同的用户将修改不同的行，但这并不总是如此。允许某些更改丢失，因为用户很可能将相同的行更新为相同的值。
- 有时会添加新行。
听起来很简单。我最初的方法是使用长时间运行的 DbContext 实例。这个 DbContext 应该跟踪实体的更改，因此当调用 SaveChanges() 时，大部分跑腿工作都会自动完成。然而许多人指出，这不是从长远来看的最佳解决方案，特别是此处。我仍然不确定我是否理解原因，而且我也没有看到我的场景中的工作单元是什么。用户自己选择何时保留更改，假设客户端总是因简单性而获胜。同样重要的是要注意，未触及的对象不会覆盖数据库中的任何数据。
另一种方法是手动跟踪更改或使用为我跟踪更改的对象，但是我对此类技术不太熟悉，并且我欢迎在正确的方向上轻推。
解决这个问题的正确方法是什么？
我知道这个问题有点空洞，但认为它更根本。我对如何解决此类问题缺乏基本的了解。在我看来，长久存在的 DbContext 是正确的方法，但知识渊博的人告诉我不然，这导致我感到困惑和不精确的问题。
编辑1 另一个令人困惑的地方是 DbSet 对象上存在 Local 属性。它邀请我使用长时间运行的上下文，因为另一个用户已发布 此处。
I'm using .NET entity framework 4.1 with code-first approach to effectively solve the following problem, here simplified.
- There's a database table with tens of thousands of entries.
- Several users of my program need to be able to
- View the (entire) table in a GridRow, which implied that the entire Table has to be downloaded.
- Modify values of any random row, changes are frequent but need not be persisted immediately. It's expected that different users will modify different rows, but this is not always true. Some loss of changes is permitted, as users will most likely update same rows to same values.
- On occasion add new rows.
Sounds simple enough. My initial approach was to use a long-running DbContext instance. This one DbContext was supposed to track changes to the entities, so that when SaveChanges() is called, most of the legwork is done automatically. However many have pointed out that this is not an optimal solution in the long run, notably here. I'm still not sure if I understand the reasons, and I don't see what a unit-of-work is in my scenario either. The user chooses herself when to persist changes, and let's say that client always wins for simplicity. It's also important to note that objects that have not been touched don't overwrite any data in the database.
Another approach would be to track changes manually or use objects that track changes for me, however I'm not too familiar with such techniques, and I would welcome a nudge in the right direction.
What's the correct way to solve this problem?
I understand that this question is a bit wishy-washy, but think of it as more fundamental. I lack fundamental understanding about how to solve this class of problems. It seems to me that long living DbContext is the right way, but knowledgeable people tell me otherwise, which leads me to confusion and imprecise questions.
EDIT1
Another point of confusion is the existance of Local property on the DbSet<> object. It invites me to use a long running context, as another user has posted here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
长时间运行上下文的问题是它不会刷新数据 - 我更多讨论了问题 在这里。因此，如果您的用户打开列表并在半小时内修改数据，她不会知道更改。但在 WPF 的情况下，如果您的业务操作是：
那么这整个就是工作单元，您可以为此使用单个上下文实例。如果您遇到最后一次编辑获胜的情况，则在其他人删除当前用户编辑的记录之前，您应该不会遇到问题。此外，在保存或取消更改后，您应该处理当前上下文并再次加载数据 - 这将确保您确实拥有用于下一个工作单元的新数据。
Context 提供了一些刷新数据的功能，但它仅刷新先前加载的数据（没有关系），因此例如新的未保存记录仍将包含在内。
也许您还可以阅读有关 MS Sync 框架和本地数据缓存的内容。
Problem with long running context is that it doesn't refresh data - I more discussed problems here. So if your user opens the list and modify data half an hour she doesn't know about changes. But in case of WPF if your business action is:
Then this whole is unit of work and you can use single context instance for that. If you have scenario where last edit wins you should not have problems with this until somebody else deletes record which current user edits. Additionally after saving or cancelling changes you should dispose current context and load data again - this will ensure that you really have fresh data for next unit of work.
Context offers some features to refresh data but it only refreshes data previously loaded (without relations) so for example new unsaved records will be still included.
Perhaps you can also read about MS Sync framework and local data cache.
在我看来，您的用户可以无限期地拥有数据副本（缓存）。用户使用缓存数据的时间越长，与 DbContext 中的数据库连接断开的可能性就越大。我的猜测是 EF 不能很好地处理这个问题，而您可能想要处理这个问题。 （例如偶尔连接的架构）。我希望实施这可以解决您的许多问题。
Sounds to me like your users could have a copy (cached) of the data for an indefinate period of time. The longer the users are using cached data the greater the odds that they could become disconnected from the database connection in DbContext. My guess is EF doesn't handle this well and you probably want to deal with that. (e.g. occaisionally connected architecture). I would expect implementing that may solve many of your issues.