我即將開始一個新項目，並決定使用哪種數據訪問技術......我真的很喜歡LINQ to SQL，原因很多，但是我應該啓動新項目使用實體框架，而不是？Linq to SQL用於新項目
我有這種感覺，實體框架更臃腫和不必要的複雜，因此說明了我正在考慮與LINQ to SQL一起考慮的部分原因......但正如我所說，這可能只是我的觀點因爲我還沒有使用實體框架。
那麼今天人們會推薦我用什麼來啓動一個新項目（注意這個應用程序將在未來幾年左右）？
乾杯 安東尼
編輯： 我們是SQL Server的店，所以我們並不需要數據庫廠商無關。
也是通過使用與我的域對象一起工作的Repository模式來抽象數據訪問atm的最佳方式？
LINQ to SQL是關於快速開發和簡單性的。如果您的數據模型很複雜，或者可能變得如此，那麼使用更強大的框架會更好。
也就是說，比您的數據訪問工具更重要的是您如何從代碼的其餘部分中抽象出它。完成之後，您應該能夠從LINQ to SQL開始，並在您超出時切換（或者當出現時）。
Linq to SQL在每個類範例的活動記錄/一個表中效果最佳。如果你需要將你的班級跨越幾個表格，或者支持複雜的繼承，那麼它可能不是最好的選擇。此外，Linq to SQL本身不支持多對多關係（有解決方法）。
如果這些聽起來不像他們會影響你，那麼Linq 2 SQL可能是一個不錯的選擇。這是一個很好的輕量級數據訪問策略。
考慮到上述限制條件，可以使用Linq to SQL來很好地實現存儲庫模式。 Google會發布幾個可行的Linq存儲庫示例。
請注意，EF 1遠未完成。它缺乏你在LINQ to SQL中找到的所有功能，其中一個更重要的功能是實際的外鍵屬性（你能想象這些功能在EF 1中不存在嗎？）
另外，EF 4幾乎具有LINQ TO SQL的所有特性，並且兩者都會生成相對可比的（代碼明智的）外部API，因此除非您編寫的代碼是LINQ to SQL特定的API，否則稍後應該相對容易地遷移到EF4，用EF4的等價物替換LINQ to SQL .dbml。
你有沒有看過Subsonic - 現在在版本3中，它基本上是一個SQL DAL的linq，它可以在5分鐘內完成整個數據庫的sql的完整linq。而它運行了T4模板，所以如果你想要添加到模板是很容易
我寫了一個相當漫長的博客帖子上的選擇。NET的ORM：
.NET and ORM - Decisions, decisions
基本上，NHibernate的是你最好的選擇。如果你堅持像LinqToSql這樣簡單的東西，可以考慮SubSonic。我不會推薦任何Microsoft選項：LinqToSql或EntityFramework。
決定是否使用存儲庫模式取決於您的需求。
我記得NHibernate的LINQ支持在它可以處理的查詢類型方面相當有限（即編寫一個不重要的查詢並且使其無法處理它）相當容易，並且通常由作者標記爲「實驗」。這有改變嗎？ – 2009-09-29 21:02:37
我可以推測Linq的各種ORM支持級別，但就這方面的數據而言，我還沒有看到任何真實的東西。這個討論應該基於真實的數據，據我所知，數據不存在。似乎要收集這些數據需要付出相當大的努力。 – 2009-09-30 11:56:24
多次討論。見：http://stackoverflow.com/questions/364740/linq-2-sql-or-linq-entities你的看法是真實的，順便說一句。如果您不需要抽象數據庫提供程序，並且您的應用程序僅在SQL Server上，請不要使用EF。 – 2009-08-24 22:31:41
雖然有一些關於L2S的令人討厭的限制，例如導航屬性不是'IQueryable'，或者無法在單個SQL查詢中檢索超過2個級別的嵌套數據結構（例如Customer/Orders/OrderItems）。一個規模並不適合所有人，我會敦促專門研究所有已知的L2S和EF限制，並在做出決定之前查看它們如何與特定項目的要求相匹配。這裏沒有「合理的默認」。 – 2009-09-29 20:59:48