在Entity Framework中关闭AutoDetectChangesEnabled的可能风险

Question

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

关于MSDN的教程说明：

  

禁用和重新启用的替代方法是始终关闭自动检测更改，并明确调用context.ChangeTracker.DetectChanges或努力使用更改跟踪代理。这两个选项都是高级的，可以轻松地在您的应用程序中引入微妙的错误，因此请小心使用。

https://msdn.microsoft.com/en-us/data/jj556205.aspx

最后一部分是关注我的。

• 您能解决一下这种优化方法可能出现的最常见问题吗？
• 什么是防止意外后果的好措施？

Answer 1

我对ChangeTracking的体验是：如果可能的话，你应该保留它。 对我来说，ChangeTracking有两个微妙的问题（对于我们，全局禁用了ChangeTracking）。 首先，在添加/删除实体时，您必须手动设置实体状态，因为通常ChangeTracking将实体状态设置为已修改/已添加（您必须手动设置已删除），并且这适用于每个实体（也包括导航中的实体）属性）。此外，在许多情况下，您必须手动设置FK。

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

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

Part 1

Part 2

Part 3 - possibly most interesting to you

Part 4

Part 5

Answer 2

始终确保您不会意外禁用EntityFramework代理类型。我有这样的问题，并花了很多时间修复它。 EF的更改跟踪与此有关，当我禁用更改跟踪时，它也会禁用代理类型。

EF使用它自己的代理类型来模仿你的类型，以便将它们的Lazy Loading应用到它们。当禁用代理类型和延迟加载时，EF只会停止加载内部实体。因此，如果您的MyClass具有属性myClass.MyAnotherClass，则它将始终为空。

就我个人而言，如果您不熟练，我建议您启用更改跟踪。我尝试使用它被禁用，花了几天试图让它工作，然后将其恢复到启用状态。它肯定会影响性能，但它非常聪明，并为您提供了很多优势。