entity-framework - 我应该使用 Entity Framework 4.1 和 MVC3 启用或禁用动态代理吗？

Question

有人可以提供一些建议或指出一些可以帮助做出此决定的博客/文章吗？这些代理对我来说似乎很陌生，我很犹豫是否使用它们。我喜欢通过在模型中使用虚拟属性来控制延迟加载的能力，但这几乎就是我能看到的所有好处。我的应用程序是一个简单的 MVC Web 应用程序，当实体经历状态更改时，我不需要将任何 Hook 连接到上下文中。

无论如何，这是我目前非常有限的利弊 list ，如果我的观点有任何偏差，请告诉我。

优点

• 在“保存”或“更新”时，我可以无缝地使用“应用更改”
• 延迟加载配置非常简单。

缺点

• 我的实体以前从未使用过代理，这是一个变化对于我自己和其他团队来说，这种方法似乎让人感到不舒服成员。
• 调试起来很困难。
• 如果我想要序列化/反序列化，则需要额外的代码
• 在“保存”或“更新”时，代理必须与从上下文中检索到的对象相同。

Answer 1

如果您谈论 EF 中的动态代理，则有两种不同的类型需要区分:

• 延迟加载代理
• 变更跟踪代理

通常，更改跟踪代理也可以充当延迟加载的代理。反之则不然。这是因为更改跟踪代理的要求更高，尤其是所有属性(以及标量属性)必须是虚拟。对于延迟加载，导航属性是虚拟就足够了。

事实上，更改跟踪代理始终还允许利用延迟加载，这是 DbContext 具有此配置标志的主要原因:

DbContext.Configuration.LazyLoadingEnabled

该标志默认为 true。将其设置为 false 会禁用延迟加载，即使创建了代理也是如此。如果您正在使用更改跟踪代理但又不想使用这些代理进行延迟加载，这一点尤其重要。

选项...

DbContext.Configuration.ProxyCreationEnabled

...完全禁用代理创建 - 也用于更改跟踪和延迟加载。

只有当您的实体类满足创建更改跟踪或延迟加载代理的要求时，这两个标志才有意义。

现在，您知道动态延迟加载代理的用途了。那么，为什么要使用动态变更跟踪代理呢？

实际上，我知道的唯一原因是性能。但这是一个非常有力的理由。将基于快照的变更跟踪与基于代理的变更跟踪进行比较，性能差异是巨大的 - 根据我的测量，50 到 100 的系数是现实的(取自一种方法，该方法需要大约 1 小时处理 10000 个基于快照的变更跟踪实体，并需要 30 到 60 秒将所有属性设为虚拟以启用更改跟踪代理之后)。如果您有一些处理和更改许多(例如超过 1000 个)实体的应用程序，这将成为一个重要因素。在 Web 应用程序中，您可能只对 Web 请求中的单个实体进行创建/更改/删除操作，这种差异并不重要。

在几乎所有情况下，如果您不想使用延迟加载代理，则可以利用急切或显式加载来实现相同的目标。基于代理的延迟加载或基于非代理的显式加载的性能是相同的，因为加载导航属性时基本上会发生相同的查询 - 在第一种情况下由代理执行查询，在第二种情况下由您的手写代码执行查询。因此，您可以在没有延迟加载代理的情况下生活，而不会损失太多。

但是，如果您希望获得合理的性能来处理许多实体，则没有其他选择可以更改跟踪代理 - 除了在 EF 4.0 中使用 EntityObject 派生实体(EF 4.1 中不是一个选项，因为它是被禁止的)当您使用 DbContext 时)或根本不使用 Entity Framework 。

编辑(2012 年 5 月)

与此同时，我了解到在某些情况下 change tracking proxies与基于快照的跟踪相比，性能并不更快，甚至更差。

由于使用更改跟踪代理时存在这些复杂性，首选方法是默认使用基于快照的更改跟踪，并仅在需要高性能且事实证明速度更快的情况下谨慎使用代理(在进行一些测试后)比基于快照的更改跟踪。