业务层应该返回DataSet/DataTable，还是对象/对象集合？

今天看到了思归的博客里面的一篇文章，感觉很有同感：

…………………………
假如你的应用inherently没什么业务逻辑或者你的应用很简单，或者你的目的就是把数据库里的数据显示出来，那就用DataSet/DataTable好了。DataSet/DataTable到底提供了不少有用的方法(过滤/排序/。。。)，而且具有在修改后端数据库后，不用修改中间编码，修改显示层的绑定编码即可将变动反应出来的灵活性。

但DataSet/DataTable往往反映了你的数据库里的Schema，你的表现层跟你的数据库里的东西的耦合如此之强，是否恰当，应该是个需要考虑的问题。但一想到DataSet/DataTable如此地方便，灵活，而且因此编码过程效率很高，何乐不为呢？

而且，一般来说，你的应用并不是只用来显示数据的，往往需要编辑(添加/修改/删除)数据。但DataSet/DataTable这样的容器提供了很好的功能，能帮你记住你的数据的状态，很符合Martin Fowler的PEAA一书里的Unit of Work模式。然后到最后，你可以用DataAdapter一次性地(虽然其中操作并不是一次性)把数据更新到数据库去。

然后你就会在很多地方操作DataSet/DataTable，即使编码难以避免地会有点重复，而且你是在直接操作数据，心里会有点不安，但想到DataSet/DataTable的种种好处，哎，这么方便。。。。before you know it，类似的操作会散居各个逻辑层，哎，什么domain model，我这database-driven programming也蛮好的。。。等到要维护时，或需要改版时再看，业务逻辑象映山红般满山遍野。。。。哎，反正我的项目比较小，重头开始吧。。。。If you didn't learn anything here, we will be looking forward to another unmaintainable project
…………………………

相关连接

1. Aaron Skonnard谈到从WebService返回DataSet对Interoperability的影响

2. Scott Hanselman又说，DataSet是只碗，不是水果，强类型DataSet是只上面画了个苹果的碗而已

3. Karl Seguin在MSDN上的文章“掌握 ASP.NET 之路：自定义实体类简介”里指出了DataSet的问题

4. Barry Gervin不同意，罗列了DataSet的种种好处

5. Jelle Druyts也不同意，称DataSet不是邪恶

6. 模式和实践里的2篇关于把DataSet用作DTO的文章，总结了其中的优弱点
Implementing Data Transfer Object in .NET with a DataSet
Implementing Data Transfer Object in .NET with a Typed DataSet

---

我是相当同意以上的观点的，不过用Domain Model在表示层编程的时候是很方便的，不过也有让我感觉头疼的地方，不错，就是O/R Mapping了。

一般来说有两种风格的Domain Model：
1．   每个对象对应于数据库中的表中一行。 Active Record模式
2．   有很多的对象（由于使用继承和模式，比如一个接口，多个实现类） Data Mapper模式

不过我没有那么讲究，项目里面大部分是用ActiveRecord模式，也就是PetShop的模式。遇到不好处理的位置（例如邮件附件和公文附件，根本就是相同的东西，却在两个表里面），就用DataMapper模式……。