Entity Framework (EF) data query

The Entity Framework (EF) accesses the Entity in three different ways.

LINQ to Entities	Direct access through LINQ to completely separate the program from the database, and LINQ automatically uses the object service for database operations internally
Object Service	The entity can be accessed through entity SQL (ESQL), and the result set is accessed directly as an object (because the result set itself is a collection of objects).
EntityClient	Through a similar ado.net approach, and Entity SQL access Entity.

EF, there is a container that manages all the objects attached to it. They track the changes of objects through a mechanism called object tracking, so that they can be persisted to the database when the user needs it. Sometimes, we may not need to change the data (for example, we simply take out a entity and then bind it to the UI), then the tracking mechanism is more redundant. In the EF, we can achieve the same effect with Mergeoption.notracking=false.

In EF, there is a query plan caching function that can cache the compiled esql. If you use the objective service, you can set it to open with System.Data.EntityClient.EntityCommand.EnablePlanCaching. If you use EntityClient, you can set it to open with System.Data.Objects.ObjectQuery.EnablePlanCaching. By default, both of these settings are true, and we don't need to worry too much. Note, however, that caching is only possible when the statements to be executed exactly match the cached statement (but the query parameters are variable, which is essentially the same principle as SQL Server's execution Plan caching principle). In addition, the cached esql is based on app-domain, and even if the objectquery<t> instance is destroyed, the rest of the objectquery<t> instance can use the cache plan as well.

The last one is that CompiledQuery is compiled on the first run, so it is slower than the normal LINQ statement the first time it runs. The general use of CompiledQuery is to declare a static variable to store it.

And it's the first time you create a ObjectContext and query the data. The following pie chart gives you the time it takes for the first time you create a ObjectContext and use it to access a database

It can be seen that only view generation one operation takes up 56% of the time, but thankfully, this operation only occurs at the first query, and then the resulting good view is cached for later use.

We can use EDMGen2.exe to generate our own View.cs and then add it to the project to compile, which will greatly reduce the time ratio of the view generation operation. According to the Ado.net Team test, compiling your own view will probably save you 28% of the time. But the results I tested on my computer were less than ideal, about 8% or so.

More details about EF query performance see ado.net Team blog article: ado.net Entity Framework Performance Comparison