如何選擇ASP.NET MVC中的數據訪問方法？

Question

我已經在C＃2.0 WinForms中編程了一段時間了。我開始涉足ASP.NET和新的MVC框架以及C＃3.5的新功能。我只閱讀了一些關於LINQ to SQL的內容，但已經做了一些測試應用程序來試用它。在我的WinForms應用程序中，我通常擁有某種數據訪問層，並且自己編寫了所有的SQL。當然，如果有什麼可以爲我做這個CRUD，我完全贊成。

我遵循www.asp.net/mvc網站上的教程，並執行了實體框架示例和LINQ to SQL示例。到目前爲止，他們看起來都很相似。 LINQ感覺更像SQL，但實體框架更像C＃。

我的問題是：

1. 是一個方法比其他更好嗎？
2. 一個比另一個有什麼好處？
3. 是否可以看到使用這兩種方法時生成的SQL？
4. 由於我是ASP新手，Web開發人員是否傾向於一方？

Answer 1

2：LINQ到SQL具有簡單（但仍遠工程）的優勢 - 但是是簡單;-p

• LINQ到SQL只適用於SQL下行服務器（實體框架是可插入的;像DBLinq這樣的LINQ-to-SQL的第三方變體覆蓋了一些其他提供者）
• 實體框架支持數據（存儲）模型和對象模型之間的更多抽象 - LINQ-to-SQL是字面值table/column => class/property [| field]
• LINQ-to-SQL實際上更「完整」它確實做：
  • EF不支持的UDF
  • EF不支持這樣子表達式調用的東西（自定義表達式樹）
  • EF不支持一些「顯而易見」的方法像Single()
  • EF沒有一些LINQ到SQL使用

基本上EF在日的TSQL的最佳化現在更多的是「v1」（甚至「v0.9」）產品。 但是（而且很重要） - EF很可能有在.NET 4.0等適當的下一個版本，其中 - 因爲LINQ到SQL將看到很少的變化。它是still being maintained，但着名的微軟have chosen Entity Framework作爲旗艦產品（而不是共同演進兩個產品本質上彼此）。你應該考慮長期計劃。

目前，I'm very happy to use LINQ-to-SQL，但EF是長期的...所以我使用存儲庫等隱藏一些血淋淋的實施細節 - 有點泄漏的存儲庫，but pragmatic。

3：使用LINQ-to-SQL，將TextReader分配給dataContext.Log; Console.Out效果很好 - 或者我有一個寫入trace.asax的文件。使用EF，ToTraceString。

4：我懷疑它由於複雜性而大打折扣。使用簡單模型的SQL Server的人員，或者很樂意擁有照亮對象模型的存儲模型的人們，目前都傾向於使用LINQ-to-SQL（從我所看到的）。具有更多複雜性和其他數據庫的人傾向於使用NHibernate;然後是一些EF。我想知道EF在.NET 4.0中的下一次發佈時會發生什麼變化...

Answer 2

使用最適合你，你的團隊和你的項目的人。只要您訪問數據，訪問數據的方式並不重要。

如果需要，可以使用普通的舊ADO.NET。