實體框架VS LINQ to SQL VS ADO.NET與存儲過程？ [關閉]

你會如何評價每個：

1. 性能
2. 發展速度
3. 整潔，直觀，可維護的代碼
4. 靈活性
5. 整體

我喜歡個人SQL，所以一直是ADO.NET和存儲過程的忠實粉絲，但我最近玩過Linq to SQL，而且被寫出個人DataAccess層的速度和決定花費的速度感到震驚有一段時間真正理解Linq to SQL或EF ......或者二者都沒有？

我只是想檢查一下，這些技術中沒有一個很大的缺陷會讓個人研究時間變得毫無用處。 例如，性能很是糟糕，對於簡單的應用程序來講它很酷，但只能帶你到目前爲止。

更新：您能夠專一於EF VS L2S VS SP而不是ORM VS SP。 我主要對EF VS L2S感興趣。 但我很想將它們與存儲過程進行比較，由於普通的SQl是我所瞭解的不少東西。

---

#1樓

LINQ-to-SQL是一項很是出色的技術，使用起來很是簡單，而且整體上會爲後端生成很是好的查詢。 LINQ-to-EF計劃取代它，但歷史上一直很是笨拙地使用並生成了遠低於它的SQL。 我不知道目前的狀況，但微軟承諾將L2S的全部優勢都遷移到L2EF中，因此也許如今一切都好了。

就我的而言，個人ORM工具一個充滿激情的厭惡（見個人謾罵這裏獲取詳細信息），因此我認爲沒有理由青睞L2EF，由於L2S了個人一切期望從數據訪問層須要。 事實上，我甚至認爲手工製做的映射和繼承建模等L2S功能增長了徹底沒必要要的複雜性。 但那只是我。 ;-)

---

#2樓

存儲過程：

（+）

• 靈活性極大
• 徹底控制SQL
• 可用的最高性能

（ - ）

• 須要SQL知識
• 存儲過程不受源代碼管理
• 大量的「重複本身」，同時指定相同的表和字段名稱。 重命名數據庫實體並在某處遺漏某些引用後，頗有可能破壞應用程序。
• 發展緩慢

ORM：

（+）

• 快速發展
• 數據訪問代碼如今受源代碼管理
• 您與數據庫中的更改隔離開來。 若是發生這種狀況，您只須要在一個地方更新模型/映射。

（ - ）

• 表現可能更差
• 對ORM產生的SQL沒有或幾乎沒有控制（多是效率低下或更糟糕的錯誤）。 可能須要干預並使用自定義存儲過程替換它。 這將使您的代碼變得混亂（代碼中的一些LINQ，代碼中的一些SQL和/或源代碼控制中的DB）。
• 任何抽象均可以產生「高級」開發人員，他們不知道它是如何工做的

---

通常的權衡是在具備很大的靈活性和失去大量時間與限制你能夠作的事情之間，但要快速完成。

這個問題沒有通常的答案。 這是一場神聖的戰爭。 還取決於手頭的項目和您的需求。 選擇最適合你的方法。

---

#3樓

你的問題基本上是O / RM和手寫SQL

使用ORM或純SQL？

看看那裏的一些其餘O / RM解決方案，L2S不是惟一的（NHibernate，ActiveRecord）

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

解決具體問題：

1. 取決於O / RM解決方案的質量，L2S很是擅長生成SQL
2. 一旦你理解了這個過程，使用O / RM一般要快得多
3. 代碼一般也更整潔，更易於維護
4. Straight SQL固然會爲您提供更大的靈活性，但大多數O / RM能夠完成除最複雜查詢以外的全部操做
5. 總的來講，我建議使用O / RM，靈活性損失能夠忽略不計

---

#4樓

首先，若是您正在開始一個新項目，請使用Entity Framework（「EF」） - 它如今能夠生成更好的SQL（更像Linq to SQL）而且比Linq to SQL更容易維護和更強大（「 L2S「）。 自.NET 4.0發佈以來，我認爲Linq to SQL是一種過期的技術。 MS對於再也不繼續進行L2S開發持開放態度。

1）表現

這很難回答。 對於大多數單實體操做（ CRUD ），您會發現這三種技術具備相同的性能。 您必須知道EF和Linq如何使用SQL才能充分利用它們。 對於像輪詢查詢這樣的高容量操做，您可能但願讓EF / L2S「編譯」您的實體查詢，以便框架沒必要不斷地從新生成SQL，或者您可能遇到可伸縮性問題。 （見編輯）

對於更新大量數據的批量更新，原始SQL或存儲過程老是比ORM解決方案執行得更好，由於您沒必要經過線路將數據封送到ORM來執行更新。

2）發展速度

在大多數狀況下，EF會在開發速度方面吹走裸露的SQL /存儲過程。 EF設計人員能夠在數據庫更改時（根據請求）更新您的模型，所以您不會遇到目標代碼與數據庫代碼之間的同步問題。 我不會考慮使用ORM的惟一一次是當您在進行報告/儀表板類型的應用程序時，您沒有進行任何更新，或者您正在建立應用程序只是爲了對數據庫執行原始數據維護操做。

3）整潔/可維護的代碼

放下手，EF擊敗SQL / sprocs。 因爲您的關係是建模的，所以代碼中的鏈接相對較少。 對於大多數查詢，實體的關係對於讀者來講幾乎是不言而喻的。 沒有什麼比從層到層調試或經過多個SQL /中間層進行更糟糕的瞭解，以便了解數據實際發生了什麼。 EF以很是強大的方式將您的數據模型帶入您的代碼中。

4）靈活性

存儲過程和原始SQL更「靈活」。 您能夠利用sprocs和SQL爲奇怪的特定狀況生成更快的查詢，而且您能夠比使用ORM更輕鬆地利用本機數據庫功能。

5）總體而言

不要陷入選擇ORM與使用存儲過程的錯誤二分法。 您能夠在同一個應用程序中使用它們，您可能應該使用它們。 大批量操做應該存儲在存儲過程或SQL中（實際上能夠由EF調用），EF應該用於CRUD操做和大多數中間層的需求。 也許您會選擇使用SQL來編寫報告。 我猜這個故事的寓意與以往同樣。 使用正確的工具完成工做。 但它的一點點是，EF如今很是好（從.NET 4.0開始）。 花一些時間閱讀並深刻了解它，您能夠輕鬆建立一些使人驚歎的高性能應用程序。

編輯 ：EF 5經過自動編譯的LINQ查詢簡化了這一部分，可是對於真正的高容量，你確定須要測試和分析在現實世界中最適合你的東西。

---

#5樓

若是你所追求的是存儲過程的強大功能和性能，以及像Entity Framework這樣的工具所提供的快速開發，那麼你可能須要考慮一種全新的方法。

我已經在一個小項目中使用SQL +進行試駕，這真的很特別。 您基本上向SQL例程添加了多少註釋，這些註釋爲代碼生成器提供了指令，而後代碼生成器根據實際的SQL例程構建一個很是好的面向對象的類庫。 有點像反向的實體框架。

輸入參數成爲輸入對象的一部分，輸出參數和結果集成爲輸出對象的一部分，服務組件提供方法調用。

若是你想使用存儲過程，但仍然想要快速開發，你可能想看看這些東西。