我应该使用实体框架 4.1 和 MVC3 启用或禁用动态代理吗？

Question

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

不管怎样，这是我现在列出的非常有限的利弊清单，如果我的观点有误，请告诉我。

优点

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

缺点

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

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）或根本不使用实体框架。

编辑（2012 年 5 月）

与此同时，我了解到在某些情况下 更改跟踪代理的性能并不更快，甚至更差。

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

Answer 2

对于使用 Entity Framework 5 的任何人，请务必查看性能注意事项一文。 第 5 节 NoTracking 查询 和 8 加载相关实体 提供您做出明智决策所需的信息。干杯。

Answer 3

我建议不要使用代理。动态代理创建会破坏依赖于运行时类型检查的组件或使其变得复杂。

例如，自动映射器将在运行时抛出类型不匹配/意外类型错误，因为您的实体将在运行时动态生成代理类型，而不是配置自动映射时传入的类型。

Answer 4

尽管动态代理有一些不错的功能，但实际上它们可能会产生许多奇怪且晦涩的错误。

例如，在我的一个类中保留了一个实体的私有变量（它正在实现批处理），我循环遍历几百万条记录，批量处理和插入它们，每 n 条记录重新创建数据上下文清理内存。尽管我从未使用过私有变量，但 EF 会将其链接到我的新对象（通过导航属性有一个引用），即使我只设置了引用 Id。

这导致所有对象在进程运行的整个过程中都保留在内存中。我必须使用 AsNoTracking 并禁用代理，以便进程按预期工作，并使内存和性能恢复到正常水平。请记住，代理还引用创建它们的上下文，这可以在内存中保留巨大的实体图，几乎不可能对其进行调试

因此，我认为您应该全局禁用代理并在小的且包含的片段中启用它们代码。调试此类问题是非常危险且不可能的，特别是当您有大型团队编码时。

更改跟踪很好，它可能证明在某些地方使用是合理的。
除非您知道自己在做什么，否则延迟加载可能会成为性能和序列化方面的一个巨大问题。我始终喜欢急切或显式加载。

Answer 5

使用自动映射器 4.2.1。新版本没有DynamicMap

var parents = parentsRepo.GetAll().ToList();
Mapper.CreateMap<Parent,ParentDto>();
var parentsDto = Mapper.DynamicMap<List<ParentDto>>(parents);