在实体框架中关闭AutoDetectChangesEnabled的可能风险

Question

为了提高Entity Framework应用程序的性能，建议进行设置AutoDetectChangesEnabled = false。

以下有关MSDN的教程指出：

禁用和重新启用的一种替代方法是始终保持对更改的自动检测处于关闭状态，并且可以context.ChangeTracker.DetectChanges显式调用或勤奋地使用更改跟踪代理。这两个选项都是高级选项，可以轻松将细微的错误引入您的应用程序，因此请谨慎使用。

https://msdn.microsoft.com/zh-CN/data/jj556205.aspx

最后一部分是我所关心的。

• 您能否给出这种优化方法可能发生的一些最常见的问题？
• 有什么好的措施可以防止意外的后果？

Answer 1

我对 ChangeTracking 的经验是：如果可能的话，你应该让它保持开启状态。对我来说，我有两个关于 ChangeTracking 的微妙问题（对我们来说 ChangeTracking 是全局禁用的）。首先，在添加/删除实体时，您必须手动设置实体状态，因为通常 ChangeTracking 将实体状态设置为已修改/添加（无论如何您必须手动设置已删除），这对于每个单个实体（还有导航中的实体）特性）。此外，在许多情况下，您必须手动设置 FK。

其次，在编辑相关实体时，您将不得不手动调用 ChangeTracking 或设置相关实体​​ - 根据我的经验，这非常复杂。这是因为 EF 在其上下文图中保留相关实体的快照，并检查它的参照完整性，而不是 DbSet 条目中的实际相关条目。

为了进一步参考，我找到了一位 EF 开发人员 Arthur Vickers 撰写的关于 ChangeTracking 的有趣文章。

第1部分

第2部分

第 3 部分 - 可能是您最感兴趣的

第 4 部分

第 5 部分

Answer 2

始终确保您没有意外禁用 EntityFramework 代理类型。我遇到了这样的问题并花了很多时间来解决它。EF 的更改跟踪在某种程度上与此相关，当我禁用更改跟踪时，它也禁用了代理类型。

EF 使用它自己的代理类型来模仿您的类型，以对其应用它自己的延迟加载。当代理类型和延迟加载被禁用时，EF 只是停止加载内部实体。因此，如果您有一个MyClass带有属性的属性，myClass.MyAnotherClass它将始终为空。

就我个人而言，如果您不熟悉更改跟踪，我建议您启用更改跟踪。我尝试在禁用它的情况下工作，花了几天时间尝试使其工作，然后将其恢复为启用状态。它肯定会影响性能，但它非常智能，并为您提供了很多优势作为交换。