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实体对象模型来操作数据库的时候应当充分考虑以上情况并结合自己的实际使用需求来决定在自己的项目中使用哪种方案。