#T#在網(wǎng)上看到一篇文章是關(guān)于講解ADO.NET Entity框架?？戳酥笊钣畜w會(huì)，在這里我就把我所看到的和大家在一起分享一下。ADO.NET團(tuán)隊(duì)最近討論了ADO.NET Entity框架的各種性能特征。ADO.NET Entity框架在12月已經(jīng)進(jìn)入它的第三個(gè)beta版本，自那時(shí)起開發(fā)團(tuán)隊(duì)就開始為開發(fā)人員提供了使用該框架的相關(guān)信息。而現(xiàn)在，則為開發(fā)人員提供了框架性能方面的信息。

本文鞭辟入里地介紹了ADO.NET Entity框架的性能，演示了如何提高簡單查詢速度的方法，并闡釋了框架的性能特征。需要重點(diǎn)指出的是，當(dāng)一個(gè)抽象層或者類似EDM（譯注：指Entity Data Model）的模塊被用來轉(zhuǎn)換數(shù)據(jù)庫的關(guān)系樣式時(shí)，會(huì)帶來一定的性能損失。

查詢與結(jié)果

本文使用了NorthWind數(shù)據(jù)庫作為模型，并創(chuàng)建了一個(gè)簡單查詢：

(NorthwindEntities ne = NorthwindEntities()) { (Order o ne.Orders) { i = o.OrderID; } } 

測(cè)試時(shí)，我們的每個(gè)查詢對(duì)整個(gè)848行數(shù)據(jù)進(jìn)行了10次遍歷。結(jié)果很有意思，第1次運(yùn)行時(shí)耗費(fèi)了4241毫秒，而接下來的每次運(yùn)行則平均耗費(fèi)13毫秒左右的時(shí)間。最耗時(shí)的一部分內(nèi)容是ObjectContext的創(chuàng)建，而在執(zhí)行任意一個(gè)訪問數(shù)據(jù)庫的操作時(shí)，都會(huì)有一些耗時(shí)的操作發(fā)生。耗時(shí)百分比值最大的是視圖生成，它達(dá)到了驚人的56%。既然視圖生成是造成性能損耗的罪魁禍?zhǔn)?，那么開發(fā)人員最好是使用命令行工具EDM生成器（EdmGen.exe），運(yùn)行時(shí)需要加上視圖生成命令參數(shù)（/mode:ViewGeneration），它的輸出內(nèi)容為一個(gè)代碼文件（C#或者VB.NET），可以包含在項(xiàng)目中。視圖的預(yù)生成可以將啟動(dòng)時(shí)間降低到2933毫秒，而對(duì)于循環(huán)遍歷操作，整個(gè)時(shí)間可以降低28%。生成視圖并隨著應(yīng)用程序一起發(fā)布是提高性能的妙方，但其缺點(diǎn)則在于視圖不再是動(dòng)態(tài)的，一旦模型發(fā)生改變，就需要重新生成以保持同步。

ADO.NET Entity框架查詢性能

需要指出的是關(guān)于性能的主要設(shè)計(jì)要素是查詢緩存。一旦執(zhí)行了查詢，它的一部分內(nèi)容就被維持在全局緩存中。由于查詢與元數(shù)據(jù)緩存的存在，使得第二次運(yùn)行的執(zhí)行速度總是比第一次運(yùn)行快。例如，如下的Entity SQL查詢：

(PerformanceArticleContext ne = PerformanceArticleContext())   
{ ObjectQuery<Orders> orders = ne.CreateQuery<Orders>();   
(Orders o orders) { i = o.OrderID; } } 

第一次運(yùn)行該查詢耗時(shí)179毫秒，但下一次運(yùn)行則只耗費(fèi)了15毫秒的時(shí)間。首次運(yùn)行與后續(xù)運(yùn)行在執(zhí)行方面的區(qū)別在于它構(gòu)建了能夠?yàn)閳?zhí)行傳遞provider的命令樹（command tree）。

ADO.NET Entity框架之LINQ查詢?cè)趫?zhí)行方式上與Entity SQL查詢相似。例如，下面的查詢：

(PerformanceArticleContext ne = PerformanceArticleContext())  
{ var orders = from order ne.Orders select order;   
(Orders o orders) { i = o.OrderID; } } 

首次執(zhí)行LINQ查詢耗時(shí)202毫秒，而隨后的執(zhí)行耗時(shí)18毫秒，兩者的差距還要低于Entity SQL?？梢钥吹剑褂镁幾g了的LINQ查詢對(duì)于性能的提高更為明顯。編譯LINQ查詢的好處在于它構(gòu)建了表達(dá)樹（expression tree），當(dāng)查詢被編譯時(shí)，后續(xù)的執(zhí)行就不需要重建表達(dá)樹了。編譯的LINQ查詢代碼看起來像這樣：

Func<PerformanceArticleContext, IQueryable<Orders>> compiledQuery 
= CompiledQuery.Compile((PerformanceArticleContext ne) => (from o ne.Orders select o));   
(PerformanceArticleContext ne = PerformanceArticleContext()) { (Orders o compiledQuery(ne)) { i = o.OrderID; } }  

注意，PerformanceArticleContext是一個(gè)委托。對(duì)于編譯了的LINQ查詢而言，第一次執(zhí)行耗時(shí)305毫秒，而隨后的執(zhí)行時(shí)間則為15毫秒。結(jié)果并不驚人，值得關(guān)注的是編譯的LINQ查詢比之常規(guī)方式的LINQ查詢，執(zhí)行時(shí)間少了3毫秒?；蛟S對(duì)于幾個(gè)查詢而言，這算不上什么，但如果有數(shù)以千計(jì)的查詢，這樣的性能提升就倍顯價(jià)值所在了。