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
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
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 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.
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
OK, that is it. Thanks for reading.
ReferencesRead Full Post | Make a Comment ( None so far )
Download Source Code Here: Source Code
Read Full Post | Make a Comment ( None so far )
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.