三层架构中多表查询是返回实体好还是集合好 讨论下
三层架构中多表查询是返回实体好还是集合好？ 这个问题一直困扰着我，拿不定主意。
如果是单表的话 实体类是不错的 遇到多表的话难不成再建一个多表的实体类？ 少个字段多个字段那岂不是要创建多个差不多的实体？？ 这样做很显然太死板了
有些朋友就想到如果是多表查询 那就返回数据集(Dataset)，这也许是大家比较认同的办法吧，可是又感觉使用了弱类型的数据集不那么的OO
恩，为了解决这个问题 那就还是用实体类吧 在数据库里创建个视图 按照视图来创建实体类(这里有可能说的不妥，一般是先建数据模型最后才生成数据库，申明下呵呵) 这样做应该也还不错
所以想问问大家的意见 一般大家是怎么做的呢？？ 求大虾指教
纠结的我头发都白了
[解决办法]
dataset用的比较多吧.有时候为了方便也会新建实体类.
[解决办法]
只是显示用DataSet就可以了......
[解决办法]
我们都是用实体类，便于扩展
[解决办法]
对于小的东西 一般用dataset，
反之用实体类 。
我们公司的项目一直用的实体类 对于楼主说的 多表查询 一般是通过关联多次查询的 虽然查询效率没dataset好 单感觉维护更好
[解决办法]
设计业务逻辑的时候不涉及数据库，自然就用不到datatable之类的东西
[解决办法]
我看楼主在问三层，问orm，那就是在学新的开发模式了，原来的dataset是弱类型，都是围绕数据库编程的，既然你要分层，那么你现在的思考方式就要变了，不能盯着数据库的多表查询，三层没有这个概念，三层的实体是先于数据库设计的，你需要什么实体就先定义什么实体，数据库访问层去迎合实体，而不是实体去迎合数据库的多表查询。
现在的orm很多都是先设计数据库，然后用工具映射自动生成实体，这不是正统的方法，EF的Code First模式才是未来。
[解决办法]
我认为如果你要追求效率，就无需三层。既然用三层，就严格按照oo的思想来
[解决办法]
顶6楼的说法,先设计实体类,最后在根据需要,来设计数据库.
可以这么说,一个实体类的数据为了优化数据存储,可以映射到多张表;反过来也是,多个数据表的数据可以映射成一个实体.
实体的设计完全是基于领域逻辑来的.
[解决办法]
增，删，改和简单的查询用ORM。
其他的复杂查询用DataTable
没必要全部追求ORM
如果你全部追求ORM，给你个需求：行转列要查询出数据来，你怎么做?ORM遇到问题了。DataTable 可以解决问题
[解决办法]
[解决办法]
如果你说的是多表关联查询，--就是说得到的是一个无可意料的 混合表。
(而不止是一张表，而是多表（可能10张），而且也不确定有张表。)
那要建这样的实体可不容易。
但是我们要的是数据：
且并不是要实体。
所以用 table 这类数据结构了， 来存放最好不过了， 比如 DataSet
要么自已定义一个动态表格类。 可以继承于DataSet ，
并增加一些你要的功能。
[解决办法]
只读的话就返回sqldatareader，有更新需要的话，就用datatable,或者dataset .
[解决办法]
莎士比亚说过：“选择实体类还是dataset这是个问题”。曾经有资料介绍dataset功能强大但占用资源较多一般有datatable
[解决办法]
大多数情况下毫不犹豫 直接DataSet
除开一些特殊情况，看此模块使用的频率如何 一般3次以上就考虑建实体了。
[解决办法]
实体集合二次筛选也很麻烦，即使有linq，但linq的效率，
[解决办法]
个人觉得，对于那些纯粹是为了展示的查询，就返回datatable或者datareader就足够了，
不需要映射到实体，比如一些报表展示。
映射到实体有个问题，就是稍微有点变化，都要修改实体，比如报表加一列，报表减一列之类的。
但对于一些涉及编辑、多功能的地方，最好返回实体集合。
但这个还有一个问题，就是得象java一样建立一个数据处理中心，
否则，返回实体实际没有任何意义。
对象的好处在于永远只有一份，无论做多少筛选操作编辑查询，永远只有一份。
不象datatable，datareader，会复制很多份。
