应该使用实体框架4.1和MVC3来启用还是禁用动态代理？ [英] Should I enable or disable dynamic proxies with entity framework 4.1 and MVC3?

问题描述

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

无论如何，这里是我非常有限的利弊列表，让我知道如果我离开了这个任何一个。

优点

• 在'保存'或'更新'，我可以与'Apply'Changes'无缝连接


• Lazy-Loading配置非常简单。

缺点

• 从不在我的实体之前使用代理，这是
  方法的变化，对我自己和团队
  成员来说似乎不舒服。


• 调试尴尬。


• 如果我想要序列化/解序列化，需要额外的代码


• 在保存或更新中，代理必须是相同的对象从上下文中检索。

解决方案

如果您谈论EF中的动态代理有两个不同的类型来区分：

• 延迟加载代理


• 更改跟踪代理

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

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

  DbContext.Configuration.LazyLoadingEnabled 
  

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

选项...

  DbContext.Configuration.ProxyCreationEnabled 
  

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

如果您的实体类满足，这两个标志只有一个含义创建变更跟踪或延迟加载代理的要求。

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

其实，我知道的唯一原因是性能。但这是一个很强的理由。将基于快照的更改跟踪与基于代理的更改跟踪进行比较，性能差异很大 - 从我的测量中，50到100的因子是现实的（取自需要大约一个小时的方法，10000个点，基于快照的更改跟踪和30到60秒使虚拟所有属性启用更改跟踪代理后）。如果您有一些应用程序处理和更改许多（例如超过1000个）实体，这将成为一个重要因素。在Web应用程序中，您可能只在Web请求中对单个实体进行创建/更改/删除操作，这种差异并不重要。

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

但是，如果你想要合理的性能来处理很多实体，那么没有什么可以替代跟踪代理 - 除了在EF 4.0中使用 EntityObject 派生实体（在EF 4.1中不是一个选项，因为当您使用 DbContext 时禁止）或者不使用实体框架。

编辑（2012年5月）

在此期间，我了解到有些情况下，更改跟踪代理与基于快照的跟踪相比性能不会更快或更差。

由于使用更改跟踪代理时的这些复杂性，首选方法是默认使用基于快照的更改跟踪，并且只有在高度的情况下才能仔细使用代理（进行一些测试后）性能是必需的，并且证明它们比基于快照的更改跟踪更快。

Could someone offer up some advice or point out some blogs/articles that could help with making this decision? The proxies seem very foreign to me and I'm hesitant to use them. I like the ability to control Lazy Loading by using virtual properties in my model, but that's pretty much all the benefits that I can see. My application is a simple MVC web application and I don't need to wire up any hooks into the context for when the entities experience a changed state.

Anyway, here's my very limited list of pros and cons right now, let me know if I'm off base with any of this.

Pros

• On 'Save' or 'Update', I get seamless with 'Apply'Changes'
• Lazy-Loading configuration is very easy.

Cons

• Never used proxies before for my entities, this is a change in approach that just seems uncomfortable for myself and fellow team members.
• Awkward to debug.
• Requires extra code if I want serialize/de-serialize
• On 'Save' or 'Update', the proxy must be the same object that was retrieved from the context.

解决方案

If you talk about dynamic proxies in EF there are two different types to distinguish:

• Proxies for lazy loading
• Proxies for change tracking

Usually a change tracking proxy also can serve as a proxy for lazy loading. The reverse is not true. This is because the requirements for change tracking proxies are higher, especially all properties - also the scalar properties - must be virtual. For lazy loading it is enough that the navigation properties are virtual.

The fact that a change tracking proxy always also allows to leverage lazy loading is the main reason why the DbContext has this configuration flag:

DbContext.Configuration.LazyLoadingEnabled

This flag is true by default. Setting it to false disables lazy loading even if proxies are created. This is especially important if you are working with change tracking proxies but don't want to use those proxies for lazy loading as well.

The option ...

DbContext.Configuration.ProxyCreationEnabled

... disables proxy creation completely - for change tracking and lazy loading as well.

Both flags only have a meaning at all if your entity classes meet the requirements for creating either change tracking or lazy loading proxies.

Now, you know the purpose of dynamic lazy loading proxies. So, why should one use dynamic change tracking proxies?

Actually the only reason I am aware of is performance. But this is a very strong reason. Comparing snapshot based change tracking with proxy based change tracking the performance difference is huge - from my measurements a factor of 50 to 100 is realistic (taken from a method which needed around one hour for 10000 entites with snapshot based change tracking and 30 to 60 seconds after making all properties virtual to enable change tracking proxies). This is getting an important factor if you have some application which processes and changes many (say more than 1000) entities. In a web application where you possibly only have Create/Change/Delete operations on single entities in a web request this difference doesn't matter so much.

In almost all situations you can leverage eager or explicite loading to achieve the same goal if you don't want to work with lazy loading proxies. The performance for proxy based lazy loading or non-proxy based explicite loading is the same because basically the same query happens when navigation properties are loaded - in the first case the proxy does the query, in the second case your hand-written code. So, you can live without lazy loading proxies without losing to much.

But if you want reasonable performance to process many, many entities there is no alternative to change tracking proxies - aside from using EntityObject derived entities in EF 4.0 (not an option in EF 4.1 because it's forbidden when you use DbContext) or not using Entity Framework at all.

Edit (May 2012)

In the meantime I have learned that there are situations where change tracking proxies are not faster or even worse in performance compared to snapshot based tracking.

Due to these complications when using change tracking proxies, the prefered way is to use snapshot based change tracking by default and use proxies carefully (after doing some tests) only in situations where high performance is required and where they prove to be faster than snapshot based change tracking.

这篇关于应该使用实体框架4.1和MVC3来启用还是禁用动态代理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！