用面向对象开发时，有必要把数据库数据都构造成对象吗？

Question

例如在描述这样一个实例：图书管系统，一个同学查看他已经借阅的书。UML大概也就是样：在代码实现的时候：按正常是：类Stuent,有一个存放类book的bookList.在数据库中提取出书的相关数据后,构造成book对像然后加入bookList.为了让书本的数据能在GridView中显示，还要增加一个转换成GridView数据源的函数。大家觉得有这个必要吗，因为取出的数据是要到GridView中显示的，直接在Student类中放一个dataset来存放book数据不是很直接吗！但是这样做，感觉有些不伦不类，呵呵，谁让数据库不是面向对象呢。用对象图来表示：
大家在做开发的时候是怎么做的呢？请教了。 

Answer 1

http://www.cnblogs.com/topic/1/
建议楼主看看这个里面的讨论的文章吧。个人都有个人的看法，不要到时候你自己都茫然了，每种方法都有优劣的。

Answer 2

http://www.cnblogs.com/topic/4/
还有这个，博客园前段时间针对这个进行过很激烈的讨论，楼主请多品味下，然后再来想想自己该怎么做

Answer 3

有本书叫 think in java 值得一看,虽然是讲java的

Answer 4

如果你的系统只是纯粹的展示数据 就没必要了
用OO开发 使用与 业务逻辑比较复杂的，
要不让 直接UI+数据源 就OK了复杂的业务关系 直接用DATASET 能表示出来么？

Answer 5

    对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。    所有,是不是要把数据库中的对象完全构造成对象,就是说看db中的数据是否可以直接映射为现实世界里的对象了!在我的一个系统中,数据库中有些日志类数据由于保留对关键数据变更做一记录(其本身也是在关键数据变更时由触发器写入的)，以便在必要时跟踪,这类数据其实本身几乎没有业务意义的，所以我没有将其构造为对象。

Answer 6

先不谈如何做架构设计,就单个将dataset返回到表示层,我个人看法是非常不合理的.我一般的做法是,返回List<T>到表示层,涉及到你的程序,我会返回List<book>假设你的作者字段保存的是一个外键值,如 "ID1215",那么我的select语句会用连接查询出
book的所有字段以及保存作者信息表的所有字段.(不是在所有情况下都要选择出外键的所有字段)假设作者信息表的字段有 author age,那么我的book类的属性会包括编号,书名,author,age假设我使用的是SqlDataReader来读取数据,我会在循环读取出,用GetEntry(sqldatareader sdr)来返回一个
book类,function GetEntry(sqldatareader sdr)
{
  book _book=new book();
  _book.author=sdr.getstring(0) / 假设
 return _book;
}在循环中,将返回的book加入List<book>中.独立出来的GetEntry方法,可以在根据不同的查询条件下都可以使用.如在上面的查询条件的基础上加上where author=@author,
这个方法根本不需要修改.如果你仅需要返回一个book实体类,也挺方便.而且以后如果新增字段时,除了新增一个属性外,再添加几处sql中的新增字段,则全部修改完成.应该说算是比较方便的.一家之言.仅供参考.

Answer 7

多多写C#或java代码 好好理解一下面向对象的编程，理解封装...

Answer 8

谢谢truelove12兄的详细解答，谢谢各位！通过这大家的解答和学习，我觉得规范的面向对像程序，还是要把数据构造成对像的，这样便于软件的构建和以后的修改。但是结合我自己的情况，还是选择B方案，将显示的数据放到dataset中。用自己能舞的动的刀，就是最好的刀。