實體框架與ADO.NET

在ASP.NET MVC3項目中，使用實體框架（使用存儲庫模式）還是使用ADO.NET與SqlConnection和SqlCommand更快，更安全？實體框架與ADO.NET

2012-03-21 Travis J

這個問題很模糊，並且會更適合程序員.stackexchange.com，因爲沒有代碼特定的答案。 – 2012-03-21 19:05:23

@ErikPhilips - 你使用EF嗎？ – 2012-03-21 19:12:57

**是** - 作爲程序員使用EF的速度會更快 - 它會隱藏您的很多實現細節，所以學習的次數少，掌握的次數少。 ** **是** - 使用原始ADO.NET在運行時性能方面會更快，因爲EF實際上是ADO.NET之上的一個層 - 並且每個附加層都會耗費一些運行時性能。但是：只要實體框架的運行時性能足夠好，足以滿足您的應用程序的需求，那麼通過使用原始ADO.NET就可以縮短所有開發時間以擠出更多的運行時性能，這真的沒有意義 - EF的性能很好足夠**！ – 2012-03-21 21:37:31

非常籠統的問題，但一些想法。

性能：當它涉及到性能，只要所有的開發者有線索

平原的SqlCommand和DataReader將顯著加快。使用.net 4.5和EF 5時，EF似乎會獲得不錯的性能提升，但普通的sql總是會更快。

在這裏看到一些數字：http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx

平原ADO.NET也支持這可能是在某些情況下非常重要的異步圖案。 EF不。 ATLEAST不是EF 4.

安全

平原SQL可能只要您使用paramaterized查詢像EF一樣安全。 EF將自動執行此操作，以防止SQL注入。因爲EF總是給你這個，所以我會認爲它更安全，但略有餘量。

可測

我發現這是一個巨大的勝利，當涉及到EF。與其嘲笑嘲笑，我使用SqlCe4對我的控制器執行快速集成測試。只要您使用EF，就很容易做到這一點。

摘要

我發現EF非常有能力和API是令人愉快的工作。如果你在做性能密集型的事情，你將不得不放入原始的SqlDataReader和SqlBulkCopy中，但是混合它們不是問題。我喜歡使用EF，因爲我的工作效率更高，我可以忍受性能損失。在哪裏我感受到大的衝擊，我將使用普通的Sql。

來源

2012-03-21 19:42:45

好帖子，但外部表現的效果真的沒有幫助。我的意思是在4ms查詢時長度是23ms。這並不是很明顯。而更加沒有意義的是速度差異並不是由於SQL性能，而是由SQL生成的。因此，通常需要4秒運行的查詢不會長達23倍（92秒）。這絕不意味着對你的帖子發表評論，但是如果做正確的數據收集（微軟顯然沒有這樣做）是很複雜的。 – 2012-03-21 20:06:47

問題在於你在考慮服務器時。放置23倍以上的cpu（或4倍於EF5）是一個相當重要的可伸縮性問題（在某些情況下）。我的觀點實際上是：使用EF，其中較慢的perf不會成爲問題。但是如果需要的話，準備好測量並下載到ADO.NET。 – 2012-03-21 20:59:34

我認爲如果你去實體框架，它會爲你節省一些開發時間，因爲它會爲你生成大部分的代碼。但對於使用SQlConnection和SQLCommand的ADO.NET，您需要編寫自己的數據訪問層的創建/更新/刪除方法。

我認真地認爲使用ADO.NET存儲過程提供了一些性能優勢，因爲執行計劃存儲在服務器中。

執行SQL語句時，數據庫必須爲其生成執行計劃。如果該SQL語句反覆運行，則每執行一次該數據庫可能都必須重新生成查詢的執行計劃。在SQL經常運行的這些情況下，將SQL移動到存儲過程可以提供更高的性能（而不是提到更高的安全性）。第一次執行存儲過程時，數據庫將生成一個查詢執行計劃，將該計劃存儲在過程高速緩存中，然後執行該存儲過程。在隨後調用存儲過程時，僅數據庫引擎必須從過程高速緩存中獲取查詢計劃，並重新運行存儲過程。因此，它跳過制定的查詢計劃對後續調用

http://msdn.microsoft.com/en-us/magazine/cc163799.aspx

來源

2012-03-21 19:06:51 Shyju

EF和純ADO.NET有很大的性能差異。 EF執行時間較慢，但在開發時間上要快很多。 – 2012-03-21 19:34:17

@WouterdeKort：同意。我更新了我的答案以包含您的觀點。 – Shyju 2012-03-21 19:41:53

我同時使用取決於項目需要的步驟。這是我的看法：

好（很曖昧）

在這種情況下我會定義爲一個產品/功能，它爲我提供了一種方式來創建用更少的代碼的解決方案寫出更好的，少跑時間錯誤檢測，以及更多功能。

在這方面，實體框架（EF）爲我提供了插入/更新/刪除語句，強類型模型以及創建動態強類型sql語句的方法。

更快

EF較慢，這取決於你的經驗/知識，也可以是幾百倍慢。有了如何使用EF的正確知識，速度差異可以忽略不計。

安全

無論ADO也不EF提供任何手段的安全性（據我所知）。安全性通常在演示文稿（IIS，Winforms等）和/或SQL服務器上進行控制。

我使用EF發現（也許我還沒有找到解決方案）的唯一主要的限制是無法爲它強類型的更新記錄，如：

UPDATE [sometable] 
SET [column1] = 'new value' 
WHERE [column2] = 'shared ID value'

哪裏，取決於重用這種方法，我要麼使用SqlCommand或寫一個存儲過程。從第一個評論

更新在關於存儲過程，實體框架（EF）是非常成熟的，在這一點上，不僅可以存儲過程從EF調用，但每個模型的數據的方法（選擇，插入，更新，刪除）可以映射到存儲過程。我沒有親自做過，但它絕對是框架的一部分。

至於從安全角度調用存儲過程，存儲過程安全性存儲在SQL服務器上。如果它不能從EF調用，那麼它將無法從SqlCommand中調用。

來源

2012-03-21 19:27:06

我會從問題中移除得更好，你是正確的，因爲它很模糊。速度是一個主要問題，所以我很高興聽到你說那裏沒有太大的差別。至於安全性，我的理解是EF不能使用存儲過程，因此會引發安全問題。感謝您的輸入。 – 2012-03-21 19:35:48

根據您對存儲過程的評論更新。 – 2012-03-21 19:39:54

實體框架與ADO.NET

回答

相關問題