问我应该在entity Framework4.1和MVC3中启用还是禁用动态代理？

EN

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

用于lazy loading

• Proxies的
• 代理，用于更改跟踪

通常，更改跟踪代理也可以作为延迟加载的代理。反之亦然。这是因为对更改跟踪代理的要求更高，尤其是所有属性--以及标量属性--必须是virtual。对于延迟加载，导航属性为virtual就足够了。

更改跟踪代理总是允许利用延迟加载这一事实是DbContext具有此配置标志的主要原因：

DbContext.Configuration.LazyLoadingEnabled

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

选项..。

DbContext.Configuration.ProxyCreationEnabled

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

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

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

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

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

但是，如果你想要合理的性能来处理许多，许多实体，除了在EF4.0中使用EntityObject派生的实体(在EF4.1中不是一个选项，因为当你使用DbContext时它是被禁止的)或者根本不使用实体框架之外，没有其他选择。

编辑(2012年5月)

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

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

对于使用Entity Framework5的任何人，请务必查看Performance Considerations文章。Sections 5 NoTracking Queries和8 Loading Related Entities为您提供了做出明智决策所需的信息。干杯。

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

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