2010-01-19 99 views
4

由於LINQ to SQL基本上是ADO.NET之上的一層,因此它需要一些翻譯。這是否意味着直接使用ADO.NET比LINQ更快?還是差別很小,以至於無關緊要?LINQ to SQL vs ADO.NET - 哪個更快?

+0

這裏有一些基準(http://www.ormbattle.net/) – yojimbo87

回答

23

它確實意味着ADO.NET更快。它還爲您提供了更多自由來優化您的SQL查詢(技術上講,您可以只使用存儲過程使用LINQ to SQL,但是您會錯過整個觀點)。

事實是,如果你真的真的真的需要優化以獲得最佳性能,那麼沒有人真的推薦使用OR/M。 OR/M:有很多考慮因素,性能明智。但是,很多網站並不真正需要優化多的性能,在幾乎相同的方式,我們可以負擔得起在.NET編程,而不是彙編程序,即使是相同種類的開銷相比,在編寫代碼低級語言。

使用LINQ to SQL或NHibernate,或者其他任何OR/M的意義在於(與.NET類似),它會給你帶來很多便利,它會爲你節省很多的時間開發,並使重構和其他後來的變化更簡單的任務。

+0

如果可能的話會給那兩票 - 永遠不會忘記維護... – Paddy

+1

我只想添加一個小細節:有很多的db-unaware開發者在那裏。他們中的一些人仍然編寫SQL,其中一些人寫的非常糟糕的SQL。一些OR/MS(如L2S)做查詢優化的相當數量擊中DB之前,所以雖然對象具體化等,可以有一點的開銷,還可以得到巨大的DB-側性能提升,如果你有DB-不知道開發者你團隊...... JMHO。 – KristoferA

5

在執行它是分數慢。但是,Linq to SQL節省了開發人員的時間,這是它的主要好處,恕我直言。

善良,

4

從技術上講,是有一定的開銷,LINQ2SQL有時會產生一些小於最佳的SQL,但除非你是做高性能或高吞吐量的工作,你可能是不太可能注意它。

我的建議是選擇適合您的要求大部分DA技術,用它去。記住像Linq2SQL或EF之類的優點是減少了開發人員在編寫重複DA層時所花的時間,並減少了代碼(理論上可能減少錯誤和減少維護 - 儘管這是有爭議的)。那麼對於性能配置後,如果您發現瓶頸,你就可以開始優化特定查詢的話,如果說是造成大的瓶頸絕對必要的,非常重要的查詢可轉換爲只是普通ado.net

2

這是事實的LINQ to SQL是ADO.NET之上的一層。但其他選項也允許您將結果保存在內存中。如果您的意圖是在檢索後立即對數據執行操作,則最好在循環內使用ADO.NET DataReader以獲得更好的性能。但是,如果您需要對數據進行進一步處理,則需要使用某種變量(如LINQ to SQL Entity或DataTable)將其保存在內存中。這兩個內存變量基本上都是在封面下以相同的方式生成的。鑑於這個事實,我想說每個選項在內存中可用的速度並不像您計劃處理數據那樣重要。