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

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

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

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

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

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

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

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

更多信息請查看IT技術(shù)專欄