.net - sql轉linq - 實體框架與LINQ to SQL




linq to sql教學 (12)

LINQ到SQL

它是僅支持SQL Server的提供者。 這是一種將SQL Server數據庫表映射到.NET對象的映射技術。 是微軟首次嘗試使用ORM - 對象關係映射器。

LINQ到實體

是一樣的想法,但在後台使用Entity Framework作為ORM--再次來自Microsoft,它支持多個數據庫主要優勢的實體框架是開發人員可以在任何數據庫上工作,無需學習語法就可以對不同的不同數據庫執行任何操作

根據我個人的經驗,Ef更好(如果你對SQL不了解),那麼與LINQ語言編寫的lambda相比,LINQ的性能要快一些。

現在.NET v3.5 SP1已經發布(與VS2008 SP1一起),現在我們可以訪問.NET實體框架。

我的問題是這個。 當試圖在使用實體框架和LINQ to SQL作為ORM之間做出決定時,有什麼區別?

我理解它的方式,實體框架(當與LINQ to Entities一起使用時)是LINQ to SQL的'大哥'? 如果是這種情況 - 它有什麼優勢? LINQ to SQL無法獨立完成什麼?


LINQ to SQL

  1. 同類數據源:SQL Server
  2. 僅適用於數據結構設計良好的小型項目
  3. 無需使用SqlMetal.exe重新編譯即可更改映射
  4. .dbml(數據庫標記語言)
  5. 表和類之間的一對一映射
  6. 支持TPH繼承
  7. 不支持複雜類型
  8. 存儲優先的方法
  9. 以數據庫為中心的數據庫視圖
  10. 由C#團隊創建
  11. 支持,但不打算進一步改進

實體框架

  1. 異種數據源: 支持許多數據提供者
  2. 建議用於所有新項目,除了:
    • 小的(LINQ to SQL)
    • 當數據源是平面文件(ADO.NET)時,
  3. 在設置模型和映射文件元數據工件過程以復製到輸出目錄時,可以更改映射而無需重新編譯
  4. .edmx(實體數據模型),其中包含:
    • SSDL(存儲架構定義語言)
    • CSDL(概念模式定義語言)
    • MSL(映射規範語言)
  5. 表和類之間的一對一,一對多,多對一的映射
  6. 支持繼承:
    • TPH(表每個層次)
    • TPT(每種類型的表格)
    • TPC(每個具體類的表)
  7. 支持複雜類型
  8. 代碼優先,模型優先,存儲優先方法
  9. 數據庫的以應用程序為中心的視圖
  10. 由SQL Server團隊創建
  11. Microsoft Data API的未來

也可以看看:


LINQ to SQL和Entity Framework在表面上看起來類似。 他們都使用數據模型提供對數據庫的LINQ查詢。

LINQ to SQL是從LINQ項目演化而來的,該項目來自於開發語言開發團隊。雖然實體框架是數據可編程團隊的一個項目,專注於實體SQL語言。 微軟始終沒有打算將LINQ to SQL進行陳述。

LINQ to SQL仍然是ADO.NET的一部分,而Entity框架具有獨立的API。 實體框架是LINQ to SQL的更高版本.Entity框架使用實體數據模型來橋接應用程序和數據存儲。 它是實體數據模型(EDM),它提供了你的概念模式的定義,以及與數據庫交互所需的數據庫模式信息,以及最後一個鏈接到兩個的映射模式。

以下是由Entity Framework(實體數據模型)執行的一些任務。

•自動生成模型中的類,並在模型更改時動態更新這些類。

•關注所有數據庫連接,以便開發人員不必為編寫數據庫而編寫大量代碼。

•提供查詢模型的常用查詢語法,而不是數據庫,然後將這些查詢轉換為數據庫可以理解的查詢。

•提供一種機制,用於跟踪在應用程序中使用模型對象的更改並處理對數據庫的更新。


LINQ to SQL真的死了嗎? 由Jonathan Allen為InfoQ.com提供

Matt Warren將[LINQ to SQL]描述為“甚至從未存在過”。 從本質上講,它只是為了幫助他們開發LINQ直到真正的ORM準備就緒。

...

實體框架的規模導致它錯過了.NET 3.5 / Visual Studio 2008最後期限。 對於不幸命名的“.NET 3.5 Service Pack 1”而言,它已經完成了,它更像是一個主要版本而不是一個服務包。

...

由於復雜性,開發人員不喜歡[ADO.NET實體框架]。

...

從.NET 4.0開始,LINQ to Entities將成為LINQ to關係場景的推薦數據訪問解決方案。


如果你的數據庫簡單明了,LINQ to SQL就可以做到。 如果你需要邏輯/抽象實體在你的表之上,那麼去實體框架。


我在here找到了一個非常好的答案here它解釋了何時用簡單的話來說明:

使用框架的基本經驗法則是如何規劃編輯表示層中的數據。

  • Linq-To-Sql - 如果您計劃在表示層中編輯數據的一對一關係,請使用此框架。 這意味著您不打算在任何一個視圖或頁面中合併來自多個表格的數據。

  • 實體框架 - 如果您計劃組合來自視圖或頁面中多個表格的數據,請使用此框架。 為了更清楚地說明,上述術語是特定於將在視圖或頁面中操作的數據,而不僅僅是顯示。 這是重要的理解。

使用Entity Framework,您可以將表格數據“合併”在一起,以可編輯的形式呈現到表示層,然後當提交表單時,EF將知道如何更新來自各個表的所有數據。

選擇EF over L2S可能有更準確的原因,但這可能是最容易理解的。 L2S不具備合併數據進行視圖呈現的功能。


我正在為擁有使用Linq-to-SQL的大型項目的客戶工作。 當項目開始時,這是一個明顯的選擇,因為Entity Framework當時缺乏一些主要功能,Linq-to-SQL的性能非常糟糕。

現在EF已經發展並且Linq-to-SQL缺乏用於高度可伸縮服務的主要功能,並且支持異步操作。 我們有時每秒有超過100個請求,儘管我們已經優化了我們的數據庫,但大多數查詢仍然需要幾毫秒才能完成。 由於同步數據庫調用,線程被阻塞,不能用於其他請求。

我們正在考慮切換到實體框架,僅限於此功能。 微軟並沒有在Linq-to-SQL中實現異步支持(或開放源代碼,因此社區可以這麼做),這是一件令人遺憾的事情。


我發現在使用EF時,我無法在同一數據庫模型中使用多個數據庫。 但在linq2sql中,我可以通過在數據庫名稱前加上模式名稱。

這是我最初開始使用linq2sql的原因之一。 我不知道EF是否已經允許這種功能,但是我記得讀過它的目的是為了不允許這樣做。


我認為如果你需要快速開發一些東西,而不需要中間的東西,那麼你需要設施來代表你的表的實體:

Linq2Sql可以是一個很好的聯盟,與LinQ一起使用釋放了一個很好的開發時機。


我認為快速和骯髒的答案是

  • LINQ to SQL是快速簡單的方法。 這意味著如果你正在研究更小的東西,你會更快,並且交付更快。
  • 實體框架是全方位的,沒有任何阻礙的方式。 這意味著如果您正在從事更大型的工作,您將需要更多時間預先,開發更慢,並且具有更大的靈活性。

這篇文章@lars發表了一些明顯的差異,但簡短的回答是:

  • L2S與對象屬性緊密耦合到特定的數據庫字段或更正確地將對象映射到特定的數據庫模式
  • L2S只能用於SQL Server(據我所知)
  • EF允許將單個類映射到多個表
  • EF將處理MM關係
  • EF將能夠定位任何ADO.NET數據提供者

最初的前提是L2S適用於Rapid Development,而EF適用於更多“企業級”n層應用程序,但是這種方式賣的很少。


這裡的答案已經涵蓋了Linq2Sql和EF之間的許多差異,但是有一個關鍵點沒有引起足夠的重視:Linq2Sql僅支持SQL Server,而EF則為以下RDBMS提供了提供者:

由Microsoft提供:

  • 用於SQL Server,OBDC和OLE DB的ADO.NET驅動程序

通過第三方提供商:

  • MySQL的
  • 神諭
  • DB2
  • VistaDB的
  • SQLite的
  • PostgreSQL的
  • Informix的
  • U2
  • SYBASE
  • Synergex公司
  • 火鳥
  • Npgsql的

僅舉幾例。

這使得EF成為關係數據存儲的強大編程抽象,這意味著開發人員可以使用一致的編程模型來處理,而不管底層數據存儲如何。 如果您正在開發一種您希望確保能夠與各種常用RDBMS進行互操作的產品,這可能非常有用。

抽像是有用的另一種情況是,您是開發團隊的一部分,與多個不同的客戶或組織內的不同業務部門合作,並且希望通過減少必須成為的關係數據庫的數量來提高開發人員的工作效率熟悉以支持不同RDBMS之上的各種不同應用程序。





linq-to-sql