1. LINQ TO SQL 和EF 特點： LINQ TO SQL和Entity Framework都是一種包含LINQ功能的ORM 也就是所謂的關系對象的映射。其中包括的有DBFrist Code Frist ModeL Frist 三種中方式 來進行和數據庫之間的訪問。只是形式不同而已本質沒有什麽區別。都是ORM 之間的轉化。最終都是來進行訪問底層的數據庫的對象 和服務。

簡單來說LINQ是為了滿足不知道怎麽操作數據庫的程序員開發設計的，LinQ 可以讓他們以一種面向數據對象的方式來思考，及持久化他們的數據。 當然最後來進行訪問數據庫的無論是Oracle SQL Server MySQL MongoDB DB2 等等 都是最終生成 SQL 語句來進行訪問數據庫的 和傳統的ADO.NET 直接來訪問數據庫沒有什麽直接的區別，只是,MicroSoft 將其 CRUD 的一些方法進行封裝了而已，讓開發使用起來更加的方便 開發的速度更加的快速 ，更加的專註於核心的業務的開發的開發 ，而不是在為這些簡單的操作而耽擱太多的時間。可以讓開發節省更多的開發的時間 去做更多的事情。

當然你使用SQL Server 中的SQL Profile 來進行 查看 其中生成的SQL , 那麽問題來了 如果Oracle MySQL DB2 MongoDB 如何進行查看生成的SQL 語句 了。那麽這個時候你需要進行 使用nuGet 來進行添加一個第三方的程序集。MiniProfiler.dll 來進行查看生成的生成的SQL 語句 當然關於如何使用 可以進行參考 （http://www.cnblogs.com/jiekzou/p/6374726.html） 博客上面具有介紹我就不一一的說了。其中 無論是LINQ TO SQL 還是 EF 最終的形式 都是通過DBContent 來進行訪問數據庫。

LINQ TO SQL 和Entity Framework 兩者的本質的區別：

EF對數據庫架構和我們查詢的中實現更好的解耦。使用EF，我們查詢的對象不再是完全對應數據庫架構的C#類，而是更高層的抽象：Entity Data Model。這為我們提供了額外的靈活性其中在性能和簡單性上面也會有所損失。 這個是必須的。 畢竟在解析中性能以及功能性都是有所損失的。

優點：LINQ TO SQL，是一個輕量級的ORM框架，為Microsoft SQL Server數據庫提供快速的應用程序開發，其優點是易於使用、簡單、高性能。Entity Framework，為創建數據庫架構和實體類之間的映射提供了更好的靈活性，它還通過提供程序支持除了SQL Server之外的第三方數據庫。 例如其中的MySQL Oracle MongoDB DB 2 等等 都是可以映射以及訪問的。

EF 6.0 經過Microsoft 的改進性能相對於EF 4.0 確實提升了不少 其中對於CRUD 的訪問。這意味著我們在系列文章中的LINQ TO DB 查詢可以同時適用於EF 4.0 以下的版本和L2S。而且，這也使得LINQ TO SQL 成為我們學習使用LINQ查詢數據庫的理想技術， 因為保持著對象和關系之間的映射的性 那麽 在使用變得的非常的簡單 以及靈活性，並且我們學習到的查詢原則和技術同樣適用於EF。

說明：.NET 3.5下建議使用LINQ TO SQL ，該版本已經完全支持成熟的LINQ；使用EF則建議使用.NET 4.0+（VS2010）以上的版本，該版本有成熟完整的EF

2.LINQ TO SQL 和Entity Framework 復雜度：

LINQ TO SQL 支持特性比較少一些；但是相對於EntityFramework支持的特性比較多，所以稍微比較復雜一些但是 兩者可以相互結合的使用。將其轉化集合 還是非常好使用的。沒必要將形式局限與 LINQ TO SQL 還是其中的LAMBDA 表達式上賣弄

LINQ TO SQL在數據表與類之間提供了一對一的映射 和一對多之間的關系等等 當然 你也可以進行對於將對象直接作為查詢的條件進行 查詢這樣的效率是非常的高的。

LINQ TO SQL只支持Microsoft SQL Server 2000及之後的版本當然你選擇的數據庫版本高一些還是比較好的 畢竟高版本的數據庫使用起來無論是性能還是操作起來都是非常的方便的，但即使是SQLServer2000也有很多限制。EntityFramework可以支持DB2, MonogoDB, Oracle, MySQL還有其他的數據庫等等。

3.LINQ TO SQL 和Entity Framework開發時間：

LINQ TO SQL很容易學，開發起來也很快，但是LINQ TO SQL有一些限制，在開發較復雜的應用時可能會產生問題。EntityFramework的能力更強，雖然學習及應用起來比較慢，但是對更多的特性的支持使得在開發較復雜的應用時可以使問題最小化。當然我建議一些初學者還是老老實實的 從ADO.NET 開始進行學起 ，畢竟 知道知其然然後知其所以然 這樣對於你寫的Linq TO SQL 還是 EF 都是幫助非常的大的。

4.LINQ TO SQL 和Entity Framework繼承：

LINQ TO SQL支持TPH，而EntityFramework支持TPH和TPT，並且對TPC也部分支持。

5.LINQ TO SQL 和Entity Framework 文件類型：

LINQ to SQL使用包含XML的數據庫標記語言(DBML)文件來映射entity與數據表。EntityFramework 使用四個文件。第一個是Entity Data Model (EDMX)，這個是在設計器中使用的。在編譯時EDMX文件產生了其他三個文件。另外三個文件中，第一個是ConceptualSchema Definition Language(CSDL)文件，其包含概念模型的XML定義。第二個是SchemaDefinition Language(SSDL)文件，其包含存儲模型的定義。第三個文件是Mapping Specification Language(MSL)文件，其包含概念模型與存儲模型之間的映射。

6.LINQ TO SQL 和Entity Framework 復雜類型的變化：

比如說，我們遇到一些復雜的表格進行關聯的時候。LINQ TO SQL不支持這種復雜類型，而EntityFramework支持。但是我們遇到這樣的問題的時候可以通過將EF 結合到 LINQ TO SQL 集合來進行查詢 並進行 處理就可以了。

 1 //例如下面進行查詢過和訂單相互關聯的數據集合
 2 
 3  var AccountList = (from u in StarList.Where(u => u.FUST_LEVEL == 3).ToList()
 4 
 5  join p in MyDataContexter.fa_brokerage_bill_table.Where(p => p.FBBT_TIME.Year == date.Year && p.FBBT_TIME.Month == date.Month && p.FBBT_STATE != 0).ToList() on u.FUST_ID equals p.FBBT_FUST_ID
 6 
 7 orderby p.FBBT_CREATETIME descending
 8 select new AccountInfo
 9 {
10 Flag = u.FUST_LEVEL,
11 UserImg = AliyunRoot+u.FUST_HEADIMAGE,
12 UserName = u.FUST_REALNAME != "" ?( u.FUST_REALNAME.Length > 3 ? u.FUST_NICKNAME.Substring(0, 3) + "..." : u.FUST_NICKNAME) : (u.FUST_NICKNAME.Length > 3 ? u.FUST_NICKNAME.Substring(0, 3) + "..." : u.FUST_NICKNAME),
13 Income = p.FBBT_BIGSTAR_MONEY.ToString("N2") ?? "0.00",
14 ShowIncome = p.FBBT_BIGSTAR_MONEY,
15 StarID = u.FUST_ID,
16 StarLevel = u.FUST_LEVEL,
17 JoinTime = u.FUST_JOINTIME.ToString("yyyy-MM-dd")
18 }).ToList();

7.LINQ TO SQL 和Entity Framework 查詢的速度和能力：

LINQ TO SQL通過DataContext對數據庫進行查詢。EntityFramework通過ObjectContext通過LINQ TO ENTITY 進行查詢。Entity Framework還提供了EDMX SQL，它是一種類似SQL的查詢語言，很適合在模型定義中定義查詢。EntityFramework還包含了 ObjectQuery類，用於對象服務在運行時動態創建查詢。最後EntityFramework還包含EntityClientProvider，它 用於對概念模型進行查詢。

 1 // 查詢銷售記錄
 2 var QWXery = (from s in XZUser.Where(e => e.FUST_LEVEL == 2)
 3 where s.FUST_LEVEL_ID == strUserID
 4 join a in MyDataContexter.fa_brokerage_sales_table on s.FUST_ID equals a.FBPT_FUST_ID
 5 group a by a.FBPT_FUST_ID into g
 6 select new
 7 {
 8 g.Key,
 9 ZCount = g.Count(),
10 ZMoney = g.Sum(p => p.FBPT_MONEY)
11 }).ToList();
12 // 查詢訂單記錄
13 var QXXery = (from s in XZUser.Where(e => e.FUST_LEVEL == 3)
14 where s.FUST_RECOMMEND_ID == strUserID
15 join b in MyDataContexter.fa_brokerage_sales_table
16 on s.FUST_ID equals b.FBPT_BUY_FUST_ID
17 group b by b.FBPT_BUY_FUST_ID into g
18 select new
19 {
20 g.Key,
21 ZCount = g.Count(),
22 ZMoney = g.Sum(p => p.FBPT_MONEY)
23 }).ToList();
24 // 聯合一下
25 var QuerList = (from z in (from s in QWXery select s).Union(
26 from a in QXXery select a)
27 select new OrderList
28 {
29 ID = z.Key,
30 GCount = z.ZCount,
31 HJMoney = z.ZMoney
32 }).ToList();
33 return QuerList;
34 }
35 else
36 {
37 // 查詢星星就可以了
38 var QXXery = (from s in XZUser
39 where s.FUST_RECOMMEND_ID == strUserID
40 join b in MyDataContexter.fa_brokerage_sales_table
41 on s.FUST_ID equals b.FBPT_BUY_FUST_ID
42 group b by b.FBPT_BUY_FUST_ID into g
43 select new OrderList
44 {
45 ID = g.Key,
46 GCount = g.Count(),
47 HJMoney = g.Sum(p => p.FBPT_MONEY)
48 }).ToList();
49 
50 return QXXery;
51 }

8.LINQ TO SQL 和Entity Framework 性能：

LINQ TO SQL和Entity Framework 在第一次進行比較緩慢 這個由於進行訪問 數據從而 在解析以及讀取數據等等 速度並不讓人滿意，但是只有在進行請求 訪問的時候速度就比較快了 因為LINQ TO SQL 和EF 都涉及到一個延遲加載的問題 第二次加載後由於讀取的數據早已放入 緩存 中 速度還是讓人滿意的 所以開發以及用戶200W 以內的數據的數據 就沒有必要去考慮這些性能的問題， 畢竟EF 6.0對於EntityFramework 做了很大的優化性能要稍微優於LINQ TO SQL。 還是非常值得使用的。 如果對於並發可以考慮采用事務或者LOCK 來進行處理這些問題。 如果真是數據量非常的大那麽查詢過的結構足夠的復雜，那麽 采用存儲過程 來做倒是還不錯的。LINQ TO SQL 存儲過程 EF 存儲過程 來做 。倒是挺好的。

9.LINQ TO SQL 和Entity Framework 優化的處理：

一直有人對於 EF 和 LINQ TO SQL 的性能的問題存在很大的質疑 當然 這個是必須的。對於我們寫的 LINQ 語句 以及 LAMBDA 的時候需要註意 就是了 理清楚表之間的關系 以及各個對象之間的關系，做到優化的查詢 等等。具體如果做 我抽時間在寫關於如何優化LINQ 表達式以及 LAMBDA 表達式做法。

以上內容 全部屬於原創！ 部分觀點 引用 了維基百科 和其他博客觀點 已經聲明！ 2017/7/5 00:23：35

LINQ TO SQL和Entity Framework 的關系 你了解多少？