在带有小DBS的断开连接的DBContext中，区分实体在Unchanged和Modified之间的状态真的很重要吗？

Question

也许我仍然习惯于手动将状态跟踪添加到我断开连接的DBContext EF实现中。但是我想知道当DBSet的大小很小时区分实体的未更改状态和修改状态时是否真的很重要。跟踪添加和删除非常简单。但是：

如果我只是在断开连接的上下文中将所有已添加或已删除的实体注册为已修改，它是否真的会影响我的性能？当我SaveChanges时，我会接受每个实体都会受到更新，而不是在真正不变的情况下被传递。我真的会失去这么多吗？

如果区分Unchanged和Modified确实很重要，并且手动修改代码以执行状态跟踪不是很简单（特别是对于可以覆盖代码的Database First），为什么要断开连接？我应该打开上下文并让ChangeTracker做它的事吗？

Answer 1

是的，这很重要。假设您有两个用户，并且两个用户都打开窗口/网页/修改数据。用户1修改实体1.用户2修改实体2.用户1保存数据。用户2保存数据。您真的希望用户2以静默方式覆盖用户1的数据吗？当它是同一个实体时，它已经够糟糕了，但至少在这种情况下，有一个解释为什么它的工作原理是这样的。在这里，数据将被覆盖，用户2甚至不想保存。

现在，您是否应该保留上下文，或者创建一个新的来保存更改的问题，更难以回答。理想情况下，是的，保持您的上下文并使用EF的内置更改跟踪，但根据应用程序，您可能不知道上下文何时可以安全处置，并且更改跟踪会产生性能成本。后者通常可以忽略不计，所以在你遇到具体问题之前我不会担心，但前者是Web应用程序的真正问题，尤其是具有长期会话和非标准会话存储的Web应用程序。是否会对您造成问题是您需要自己衡量和/或决定的事情。

Answer 2

如果您对数据存储并发访问，则无法区分Unchanged和Modified的主要问题是：

• 假设您从商店获得实体图表并将其发送到客户端（断开连接）

• 客户端仅修改单个实体E，更改属性A

• 同时另一个客户更新了实体E，更改了属性B

• 稍后您回到E并继续进行同步

• 如果您将整个实体标记为已修改的EF将生成完整更新，您将重置其他客户端所做的更改

  < / LI>

因此，除非您有并发跟踪，否则您将失去一些更改！