對(duì)于ADO.NET TEAM 的測(cè)試結(jié)果，自己編譯的話大概會(huì)節(jié)省28%的時(shí)間。不過我在自己電腦上測(cè)試的結(jié)果沒有那么理想，大概是一半左右的時(shí)間，創(chuàng)建ADO.Net數(shù)據(jù)庫(kù)進(jìn)行解釋說明。

從第二階段開始，性能的優(yōu)劣就非常明顯的展現(xiàn)在我們面前，第二階段到第六階段，不論操作數(shù)據(jù)量的大小，圖中的耗 時(shí)比例幾乎是相同的。Entity Framework無(wú)可爭(zhēng)議的以極高的效率在三種方案中脫穎而出，而LINQ to SQL的龜速修改和刪除操作消耗的時(shí)間幾乎是EF的10倍，ADO.net在添加數(shù)據(jù)上的表現(xiàn)實(shí)在不盡如人意，這也跟我們項(xiàng)目底層寫法有關(guān)。

從上面的測(cè)試結(jié)果可以看出，創(chuàng)建ADO.Net除去EF在初次操作數(shù)據(jù)是延遲的3秒鐘（初步認(rèn)為是初始化時(shí)間），EF的平均效率是LINQ to SQL的6倍，是當(dāng)前項(xiàng)目機(jī)制的4倍，這是非?？捎^的效率提升，不難理解為什么微軟幾乎放棄了LINQ to SQL，全力支持EF了。 #t#

***次創(chuàng)建ObjectContext并查詢數(shù)據(jù)時(shí)耗費(fèi)了大量的時(shí)間，原因是什么？有沒有什么優(yōu)化的方法？本文將創(chuàng)建ADO.Net給出一個(gè)合理的解釋。

下面這個(gè)餅狀圖給出了***次創(chuàng)建ObjectContext并用其訪問數(shù)據(jù)庫(kù)時(shí)各種操作所占的時(shí)間比

從中可以看出僅僅創(chuàng)建ADO.Net一個(gè)操作就占用了56%的時(shí)間，不過令人欣慰的是，這個(gè)操作只出現(xiàn)在***次查詢的時(shí)候，之后生成好的View會(huì)被緩存起來(lái)供以后使用。一個(gè)View.cs文件的樣本如下：