Getting performance benefit from DbContext[EF 5] in Entity Framework

Posted on November 1, 2012. Filed under: .Net, C#, Code-First, dbcontext, ef5, Entity Framework | Tags: , , , , , |

I did talk about the distributed architecture here with Entity framework code-first.

Now I would like to reminds you about the performance benefit features come with DBContext and it will also help you to extend your repositories and queries. Here is the followings:

No Tracking and Auto-Compiled Queries: 

In my early version of repository pattern, I have used ObjectQuery to get the features  of MargeOption and EnablePlanCaching properties.  

Setting MergeOption to NoTracking has helped us to take advantage of the EF ability to return data that doesn’t need to be tracked by the context. Say I don’t have any plan to make changes to that data. Therefore, I like to avoid the performance hit taken when EF creates ObjectStateEntry instances for each object it’s tracking, as well as forcing the context to be aware of any changes made to those objects.  EF Team has realized needs here and they have provided you an extension method of IQueryable - AsNoTracking()[Where(expression).AsNoTracking()].

Settting EnablePlanCaching to true has been used for enabling the caching plan first time it has been executed and next there was no more complexity for creating TSQL from LinqToEntities. You could also achieve this by using CompiledQuery Class to re-use precompiled query. Unfortunately there is no way to use CompiledQuery in DbContext API. CompiledQuery works only with ObjectContext. If we are using Code First, we are using the DbContext API. EF team has provided auto-compiled queries, which work very differently than CompiledQuery. Instead of your writing code to compile each query and then invoking each as needed, Entity Framework caches the generated SQL for you as a background process, then searches the cache for already compiled queries when you execute any query. It solves many issues of pre-compiled queries and gives us flexibility to cached 800 queries Item. And most wonderful news is you don’t need to write any code or project conversion to 4.5 to achieve this. All you need is .NET 4.5 runtime in your machine.


Find Method:

As you know, Find method is providing you to find object with its key and there is also performance benefit lies here. The Find method will first look in memory for a matching object that is being tracked by the context. If that is found in memory, then Entity Framework won’t bother querying the database. So, no more visit to database and mapping complexity if it is already there my memory.

Turn off Detect Changes and Validation:

I have found DBContext more organized and friendly in place of ObjectContext. Now user has the full flexibility to turn off and turn on the calling of change detection and validation. You can find this under the Property Configuration. Change tracking and the DetectChanges method are a part of the stack where there is a penalty of performance. For this reason it can be useful to have an idea of what is actually going on such you can make an informed decision on what to do if the default behaviour is not right for your application. If your context is not tracking a large number of entities you pretty much never need to switch off automatic DetectChanges otherwise I will suggest you turned it off and call DetectChanges where it seems necessary.

First Level Caching

There are also some features like Local property which provide you the first level in-memory caching objects available in state entries without the deleted marked objects and you can get the benefit if you want during the life time of a Context instance.

OK, that is it. Thanks for reading.


Read Full Post | Make a Comment ( None so far )

Implementing Undo/Redo feature for DbContext of Entity Framework Code-First

Posted on October 11, 2012. Filed under: .Net, C#, Code-First, EF4, Entity Framework, WCF | Tags: , , , , , |

Download Source Code Here: Source Code

I was curious about change tracking and property values of DbContext and  while playing with that I decided to write snapshot manager which would  take snapshot of my each changes by storing entries And this manager also allow me to undo and redo my changes with DbContext.

DbContext will check all the entities of all types when change tracking is enabled and also verify if they have any changes in their data. Automatic Change tracking is enabled by default. Disabling it would not trigger the DbContext update for each change in the entity. Actually it maintains the state of entities. It uses this to determine the changes needed to be pushed to database when SaveChanges() is called.

The Undo and Redo features allow you to easily correct mistakes or based on some scenario, as well as free you to experiment with different routing and data mapping decisions. Undo reverses the last action you performed, and Redo undoes the last Undo action.

So let’s come to point of creating our snapshots of changes. Since DbContext still doesn’t give any event of DbContext.DetectChanges()execution, I have decided to keep my snapshot in my Repository’s CUD( Create , Update , Delete) operations and also allow user to call it explicitly whenever it is needed- Click here to read my Article in Codeproject about this topic.

Read Full Post | Make a Comment ( None so far )

Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: