一些争论的问题

当我们在层之间调用一些方法来获取数据时,将怎样接受数据呢?是用DataSet/DataTable,还是用自定义实体类对象集合呢?这是.NET架构师和开发人员之间争论最激烈的一个话题.在GOOGLE上搜索诸如 DataSet vs custom entities,DataSet vs custom collections 或者DataSet vs domain object,可以看到许多关于该主题的讨论,这两种方法有各自的优缺点,在不同的体系结构中都有自己的作用.

DataSet/DataTable的缺点可以分为三类:性能和扩张的局限性,数据的表现形式,业务规则验证.

如果只需用传递一行数据,仍需要创建和传递一个完整的DataSet/DataTable(这需要一些系统开销)因为它是驻留内存的小型数据库,所以需要一定得系统开销.它与RDBMS中的关系表格模型密切相关,没有一个清晰的,可自定义,面向对象的数据表示方式.尽管同IDE集成的很好,但每次数据库结构发生一点更改,就必须重建类型化DataSet,这比自定义集合类难度大.而最让开发人员头疼的是很难对DataSet添加自定义业务和验证逻辑.

当然DataSet也不是意味着在设计中完全没有用处.实际上在从DAL向BLL(不是BLL到UI)传递数据时偶尔会用到DataSet.在DAL中需要用到ADO.NET中的类,因为DAL是用数据库交互的地方,因此利用DataSet还是有意义的,并且只要生成了DataSet/DataTable,不需要额外的系统开销就能将它传递到BLL.而BLL才是添加验证逻辑的地方,并且在验证时它能将DataSet/DataTable中的数据转换到自定义的业务对象集合中(ToList<T>()等),这些自定义集合能被传递给UI,在UI中有一组功能强大的针对数据的OOP类,可以进行数据绑定,并且易于使用.

使用自定义的业务实体对象集合则显得很灵活,它可以用在两个地方:DAL和BLL之间,BLL和UI之间.在第一种情况下很简单,只是对数据库中的数据象征性的进行封装,没有对数据库进行增,删,改的方法.在这种情况下,实体类作为一个容器来保存两个层之间传输的数据.

第二种情况下,类则要复杂些,不但要封装数据,还要有对其父对象和子对象进行引用的其他属性,还要操作数据的实力方法.也就是常说的域对象(domain object)而不仅仅是实体类,一个实例完全代表了域中的一个元素(一份订单,一个雇员...)相对使用

自动创建的强类型化的DataSet(有现成的排序和过滤功能)创建实体类和域对象更复杂,要写更多代码,但是更灵活,占用较少的内存,因为使用了按需载入数据模式(lazy-load),只载入需要的数据,而不是将单个查询得到的所有内容同时载入.还可以给域对象增加自定义验证逻辑

tips:使用自定义对象更灵活,更优雅,适合需要很多验证逻辑的场景中,但是需要花费额外时间和精力去设计编写代码,这要自定义实体类才能显示出优势,如果只是简单的取得数据,那就用强类型化的DataSet,更方便快捷.

更多资料请看 Marco Bellinaso 写的网站开发解析一书

下一篇:使用存储过程还是使用SQL文本?