進行ADO.Net性能測試數據分析
用于在某個時候只返回一頁記錄的技術之一是建立一個SQL語句，該語句包含一個WHERE和ORDER BY子句，并有TOP判定。這種技術依賴于識別每個唯一行的方法，那么，Oracle是否有計劃給Visual Studio編寫獨特的ADO.Net性能呢？
測試環境當然就是我這臺筆記本了，受限與硬盤轉速，運行起來一定是不如臺式機的，但至少保證了三個方案相同的軟硬件環境：Windows Server 2008，Visual Studio 2008，MS SQL Server 2008，清一色的***產品。
測試分成六個階段，數據量分別為10，10，100，1千，1萬，10萬逐級增長，分別測試了讀取、寫入、更改、刪除四個基本的操作的耗時，結果如下（時間單位：秒）：
| ***次讀寫10條數據 | |||||
| 讀寫方式 | 讀取耗時 | 添加耗時 | 修改耗時 | 刪除耗時 | 平均耗時 |
| 當前機制(簡化) | 0.007 | 0.35 | 0.02 | 0.014 | 0.09775 |
| LINQ to SQL | 0.023 | 0.083 | 0.102 | 0.068 | 0.069 |
| Entity Framework | 0.238 | 3.084 | 0.009 | 0.006 | 0.83425 |
***階段測試結果非常出人意料，ADO.Net性能和LINQ to SQL操作數據的時間都控制在0.5秒以內，非常的迅速，但是Entity Framework在添加這步表現非常差，由于這五步是連續測試，其中添加數據是***步操作，而EF在在進行***步操作的時候足足延遲了3秒鐘！這3秒鐘 到底EF在做什么？
從第二階段開始，性能的優劣就非常明顯的展現在我們面前，第二階段到第六階段，不論操作數據量的大小，圖中的耗 時比例幾乎是相同的。Entity Framework無可爭議的以極高的效率在三種方案中脫穎而出，而LINQ to SQL的龜速修改和刪除操作消耗的時間幾乎是EF的10倍，ADO.Net性能在添加數據上的表現實在不盡如人意，這也跟我們項目底層寫法有關。 #t#
從上面的測試結果可以看出，除去EF在初次操作數據是延遲的3秒鐘（初步認為是初始化時間），EF的平均效率是LINQ to SQL的6倍，是當前項目機制的4倍，這是非常可觀的效率提升，不難理解為什么微軟幾乎放棄了LINQ to SQL，全力支持EF了。
