Should I enable or disable dynamic proxies with entity framework 4.1 and MVC3?

by

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.

More Related Contents:

  1. Code-first vs Model/Database-first [closed]
  2. How do I detach objects in Entity Framework Code First?
  3. Order navigation properties when using Include and/or Select methods with EF 4.1 Code-First?
  4. Entity framework code-first null foreign key
  5. How do you ensure Cascade Delete is enabled on a table relationship in EF Code first?
  6. Entity Framework Code First : Setting up One-To-One foreign key association using Annotations
  7. Entity Framework: One Database, Multiple DbContexts. Is this a bad idea? [closed]
  8. Ignoring a class property in Entity Framework 4.1 Code First
  9. Entity Framework 6 Code first Default value
  10. ORM Entities vs. Domain Entities under Entity Framework 6.0
  11. EntityFramework code-first custom connection string and migrations
  12. EF Code First “Invalid column name ‘Discriminator'” but no inheritance
  13. EF Code First: How to get random rows
  14. Debug code-first Entity Framework migration codes
  15. Entity Framework loading child collection with sort order
  16. How to map table splitting in EF Code First?
  17. How to create index in Entity Framework 6.2 with code first
  18. DbSet.Find method ridiculously slow compared to .SingleOrDefault on ID
  19. Entity Framework 4.1 default eager loading
  20. How to pass parameters to the DbContext.Database.ExecuteSqlCommand method?
  21. mapping private property entity framework code first [duplicate]
  22. What is the syntax for self referencing foreign keys in EF Code First?
  23. How to create index in Entity Framework 6.2 with fluent configuration
  24. Mocking or faking DbEntityEntry or creating a new DbEntityEntry
  25. How to use Entity Framework to map results of a stored procedure to entity with differently named parameters
  26. EF 4.1 loading filtered child collections not working for many-to-many
  27. Entity Framework Validation confusion – maximum string length of ‘128’
  28. LINQ To Entities + Include + Anonymous type issue
  29. Can anyone spot why I keep getting this error testing the EF 5 beta
  30. Entity framework code first delete with cascade

Leave a Comment