业务层应该返回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模式……。

 

你可能感兴趣的:(Datatable)