EF6 Code First场景下WinForms不同dbContext跟踪对象如何同步？

认知前提澄清 #

微软给出的「每个窗体持有一个全生命周期DbContext」的建议，仅适用于窗体生命周期短、无跨窗体共享编辑实体、无外部服务并发修改数据库的场景，你的业务存在跨窗体共享编辑ClassB、外部服务更新数据库的情况，不需要教条遵守该建议。

你列出的方案评估 #

• 方案1：按操作创建短生命周期DbContext
  不存在“违背官方建议”的问题，WinForms场景下完全可用。每次数据查询、保存操作都用using块新建DbContext，用完立即释放，天然不存在跨上下文实体同步的问题，同时能避免长生命周期上下文带来的过时数据、内存占用膨胀、ChangeTracker性能下降等问题。唯一需要注意的是如果需要做窗体级的未保存改动缓存，不要依赖DbContext的变更跟踪器，自行在ViewModel层实现缓存即可。
• 方案2：跨窗体共享同一个DbContext
  仅适合小范围窗体组（比如ClassAForm和它弹出的所有子窗体）使用，如果全局共享会导致上下文生命周期过长，外部服务修改数据库后上下文内的实体无法及时同步，且一处操作出错导致上下文状态异常会影响所有关联窗体，故障影响范围过大。
• 方案3：手动处理实体附加/分离
  维护成本极高，很容易出现同主键实体重复跟踪、状态标记错误等问题，仅作为没有其他方案时的兜底选择，不推荐。
• 方案4：事件传递更新实体手动同步
  可落地但存在局限性：收到更新后的ClassB实体后，需要先判断当前上下文是否已跟踪同主键的ClassB实体，若已跟踪则调用DbContext.Entry(旧实体).CurrentValues.SetValues(新实体)更新属性值，再同步更新ClassA的导航属性即可避免保存异常。但该方案无法感知外部服务对ClassB的修改，依然存在数据过时的问题。

最优方案选择 #

根据你的业务特性二选一即可：

场景A：窗体生命周期短、对外部服务更新的同步实时性要求低 #

采用同窗体组共享DbContext+手动刷新的方案：

1. 打开ClassBForm时，将ClassAForm持有的DbContext传递给子窗体，两个窗体共用同一个上下文，ClassBForm内对ClassB的修改会被变更跟踪器自动同步，ClassAForm的导航属性会自动更新，无需额外处理。
2. ClassAForm关闭时统一释放DbContext，避免上下文生命周期过长。
3. 若需要同步外部服务的修改，增加手动刷新按钮，调用DbContext.Entry(classB实例).Reload()即可拉取数据库最新值覆盖本地实体。

场景B：窗体生命周期长、需要及时同步外部服务的修改 #

直接采用短生命周期DbContext方案，完全放弃长生命周期上下文的设计：

1. 所有数据库操作都在using块中创建临时DbContext，用完立即释放。
2. ClassAForm监听ClassBForm的保存事件，收到事件后重新查询数据库中的ClassA及关联ClassB，更新界面绑定即可，不存在跨上下文同步的问题。
3. 该方案和你现有Web项目的DbContext使用逻辑一致，团队学习成本低，出问题的概率最小。

内容的提问来源于stack exchange，提问作者PTLEng