【引自lornshrimp的博客】LINQ to SQL雖然將數據庫操作和業務邏輯隔離開來，使開發人員能夠使用單一的語言和知識能夠方便的操作數據庫并處理業務邏輯。但是這畢竟是微軟O/R解決方案的第一個版本，相比相對成熟的DataSet數據集解決方案來說，我們還是可以看到一些不足。

首先，我們注意到所有的數據實體并沒有從一個基類中派生，這使得給開發通用的數據實體操作器帶來了不便。相對于強類型數據集都從DataSet基類派生，筆者認為數據實體這樣做并不是一個很好辦法。因為我們可以從DataTable的Columns集合中枚舉某張數據庫表中的所有字段，卻不能夠從某個數據實體中枚舉該數據庫表的所有字段。雖然我們可以通過使用反射的方法獲得，但是這樣顯然并不好。

同理，DataContext也沒有提供一個獲得所有數據實體的集合的方式，我們無法獲得一個DataContext中所有的數據實體，與此相對應的是，即便是強類型數據集，我們也能夠通過Tables屬性獲得該數據集中所有的數據表。

一個典型的例子就是，在筆者的上一本書《ASP.NET 2.0網站開發技術詳解》中，提到了一個在多服務器部署的N層應用程序解決方案中實現的中間層數據緩存的項目。在該項目中，就是通過枚舉內容中駐留的數據集的數據表的方式來確定某張數據庫表中的數據是否被緩存（當然還通過了其他一系列的方法來判斷），而如果使用LINQ to SQL，這樣一個通用的數據緩存方案就很難實現了。

同樣，如果希望開發一個快速開發平臺，通過配置的方式來實現數據的呈現和處理，比如希望通過配置XML文件來控制實現GridView列表或者Edit詳細界面顯示的字段的話，目前版本的LINQ to SQL便無法實現了。

再如，假設有這么一個需求，需要查詢指定數據庫表中某個數據類型為字符串型的字段含有某個指定值的記錄，那么使用LINQ to SQL實現也會比較困難。

另外，我們知道DataSet數據集中還有一個數據版本的概念，一共有Original、Current、Proposed、Default四種版本，我們在對數據進行操作時可以根據數據行的不同版本值以及其他條件決定是否對數據進行更新，也即AcceptChanges或RejectChanges。而在LINQ to SQL中，要獲得實體數據的變更卻非常麻煩，必須使用DataContext的GetChangeSet方法來獲得，而且獲得的變更集能夠提供的信息也實在太有限，要對某一具體數據取消更新也很困難，基本上可以認為是不可能的。

所以，當我們在考慮使用數據集方式還是LINQ to SQL實體對象模型來操作數據庫的時候應當充分考慮以上情況并結合自己的實際使用需求來決定在自己的項目中使用哪種方案。

更多信息請查看IT技術專欄