Entity Framework(EF)数据查询

Entity Framework(EF)存取Entity的三种办法。

LINQ to Entities 直接通过LINQ存取,可完全将程序与数据库分离,由LINQ在内部自动使用Object Service进行数据库操作
Object Service 可以透过Entity SQL(eSQL)来存取Entity,并且直接以对象的方式来存取结果集(因为结果集本身就是对象的集合)。
EntityClient 通过过类似ADO.NET 的方法,以及 Entity SQL 存取 Entity。

EF,有二个容器管理着其中全部附着在其上的指标。它们通过一种叫Object
Tracking的建制来跟踪对象的成形,以便于在用户需求的时候把这几个变化持久化到数据库中去。有时候,我们恐怕并不必要改动数据(比如大家只是简单地取出三个Entity然后把它绑定到UI上边去),那么在这些时候,Tracking机制就比较多余了。在EF中,我们能够以MergeOption.NoTracking=false来获得一致的机能。

在EF中,有个Query Plan
Caching的职能,它能够Cache编写翻译后的ESQL。若是选用Objective
Service,可以用System.Data.EntityClient.EntityCommand.EnablePlanCaching将它设置为打开。如若利用EntityClient,能够用System.Data.Objects.ObjectQuery.EnablePlanCaching将它设置为开辟。暗中认可情状下,那四个设置都以为True的,不要求大家很多担心。可是要专注的是只有要实践的语句与已缓存的口舌完全标准匹配的时候才能使用缓存(不过查询参数可变,其实那个规律跟SQL
Server的推行安排缓存原理差不离)。其它,缓存的ESQL是依据App-Domain的,而且正是是ObjectQuery<T>的实例被灭绝了,其他的ObjectQuery<T>实例照样能够选拔缓存铺排。

最终一个是CompiledQuery会在第一遍运转时展开编写翻译,所以在首先次运维时,它比不奇怪的LINQ语句还要慢。CompiledQuery的一般用法是宣称3个static的变量来存款和储蓄它。

还有便是首先次创制ObjectContext并询问数据时消耗了大气的流年。下边那么些饼状图给出了第③次创制ObjectContext并用其访问数据库时各个操作所占的岁月比

图片 1

从中能够看来仅仅View
Generation一个操作就占用了55%的日子,可是令人欣慰的是,这么些操作只出现在率先次查询的时候,之后生成好的View会被缓存起来供之后采纳。

大家能够利用EDMGen2.exe来协调生成View.cs,然后把它到场到工程中编写翻译,那样会大大缩减View
Generation操作所占的时日比。依据ADO.NET TEAM
的测试,本人编写翻译View大约会节省28%的光阴。然则小编在祥和电脑上测试的结果没有那么美丽,大约是8%左右。

至于EF查询质量方面更详细的内容参看ADO.NET Team blog的文章:ADO.NET
Entity Framework Performance
Comparison

相关文章