一个DAO的设计的小问题

关于join这种操作到底是放在DAO中还是生成值对象后到了业务逻辑层再关联其他类的数据，我一直比较迷茫？
也就是在设计数据Bean的时候（应该就是PO吧？）是应该只对应一个表，还是对应一个业务应用？

我们的原来的系统是在一个PO中把一个业务应用需要取得的数据都在DAO中用left join从其他的数据表中取得

我认为这样实际上就是把业务逻辑放到了DAO中，不知道这样理解对不对？
我的想法是在DAO中只负责一个表的操作，然后对一个对应这个表的PO赋值，传到业务逻辑层后如果需要其他表的信息，再从其他DAO生成的PO中取值。
也就是说对一个业务所需信息的组装放到了业务逻辑层，而不是DAO那里。
但是这样做取得一个业务所需要的数据却需要多次连接数据库，这样是不是对效率有所影响呢？

不知道各位有何指教？
另外，我们的程序是桌面应用，但将来也可能会跑在web上。在桌面上这个效率问题可能不太严重，但是将来到了web上，远程多次连接数据库取得关联数据的方式，会不会对效率产生严重影响？

另外的问题就是如果将复杂的针对业务的查询放到DAO中
那么针对这个DAO的更改可能就不再是一个人负责，因为完整的业务流程可能需要很多个逻辑上分离的功能，而每个功能交给不同的人开发，每个人就都需要操纵这个DAO类
而在CVS控制的开发中多人操作一个类我感觉不是很方便，不知道其他人都如何解决的？

感觉楼主的思路还是数据驱动的思路, 如果表间关系简单这种做法还可以,但显然表间关系比较复杂,不然楼主也不会有问题了. 我的建议是楼主要转换设计思路,用OO来解决问题, 具体一点说就是要把重点放在设计业务对象,包括业务对象关系上,而不是关心什么表,left join等,我能想到楼主的应用中多半没有业务对象,否则不会有这些问题, 另外建议看一下前段时间在gigix的blog上关于domain object模式和transaction script模式的讨论,相信对楼主的问题会有所帮助.

首先，多谢jxb8901的关注、、、有人回复感觉真好  ToT

然后，先说说理论上的情况吧
根据我对domain model的理解（如果不对，请随意指教^_^）
它的出现是为了在分析和设计上得到纯粹的OO系统
而不再是一个功能分散到很多层面上的“OO”
打个比方:
比如我的系统中有一个篮球，那我就构造一个真正的篮球在层间传输
并且属于篮球自身的功能我都调用这个object的方法
而不是将篮球的属性传到表现层，让它们在那给我画出一个篮球
但是，这样我们就要维护一个真正的对象，并让它在各个层之间传来传去
我记得DTO的出现不就是在web应用中为了减小网络的负担才出现的纯粹的VO吗？
如果在web传一个既有值又有各种方法代码的对象，是不是有点重呢？
其实以上说的都是小问题
最关键的问题是我就算使用了domain model
我觉得我用不好它,关于service和domain object的责权，我现在也想不清楚
gigix也在讨论的时候说过“我还不信有谁面对一个新的领域，一上来做个Domain Model就能做得“这么cool”了。”

再然后，说说实际上的困难
关于我这个系统，是我来到这个公司之后接手一个离开的团队的系统
简单介绍一下
这个程序有两层，底层就是我前面说的DAO（包含部分业务逻辑的）
然后就是Swing的GUI层，所有的业务逻辑全部写在GUI层
有的是几个功能界面写在一个类里,一个方法200行算少的
（第一次看到它的时候我想起VB了）
我就是想把业务逻辑层剥离出来（为了将来在web上的应用）
所以才牵扯出前面的问题
其实不是我不想做的更好，现在的问题是老板已经在发飙了

所以，如果可能的话
我想还是照着大家都在做的三层结构的方法做，毕竟比较简单
当然也希望jxb8901兄弟能详细介绍一下domain model的好处和实现思路
我也好跟老板侃侃，看能不能多给点时间改造一下程序

最后，希望能继续得到你的关注^_^

65次阅读为什么没人回复呢？
难道是我问的问题太弱了？
要是太弱了各位骂两句也行啊

我认为，在 DAO 中做 join 操作不等于放了业务逻辑，DAO 本就是为业务层提供访问数据的统一接口，是对数据库底层操作的封装。所以，应该在 DAO 中封装 join 操作而不应该放在业务层来做。

如果 DAO 只对单表操作，把表的关联放到业务层，无疑对性能有极大影响。毕竟，业务层是不知道怎么对数据库操作进行优化的。

100% 严格的分层是不现实的，或者，叫“过度设计”？

这是持久层设计的问题，你的entity object的设计问题

这样的设计是关系数据库的思路了

我想首先我们要达成一个共识,就是相信OO能给我们的"痛苦"带来解脱,构建一个真正OO的系统是我们的追求,如果连这一点都不能认同那其它的就不要谈了. 我这里说的是真正的OO的系统,而不是指OO的编程语言,实际上这两者没有关系.而transaction script的提出,我想主要就是指用OO的语言做出来的过程式的系统,这类系统我们见的太多了,而真正OO的系统却太少了,我的理解domain object就是指的真正OO的系统. 另外我讲OO是我们的追求,是目标,如你所说我们一下也不可能做完善理想的系统,但心中应该有这样一个远景,我们要使系统尽量OO,因为我们要让自己尽量轻松.

这是OO技术的具体运用问题,OO的关键是对象,对象的关键是职责,我想你不可能要一个篮球做掉所有和篮球相关的事吧?篮球要显示?交给擅长展示的人去负责好了,篮球要保存?交给仓库好了,一个领导如果这样分配任务,你会不会认为他不公平呢?我想这是"隐喻"的威力,让事物回归本来面目才是真OO.

如果真是讨论OO,这时候就不要讲什么DTO,VO,它们只是技术上的需要,而不是domain的需要.再说了,你所说的"重"和对象中"有各种方法代码"有关系吗? 两个字段一个方法的类和一个字段两个方法的类在传递中相比,哪一个更重呢?

这就是我们见得太多的用OO语言做的过程式的系统,当然不是讲这种系统一无是处,如果它不让人心烦,尽可以用这种方法做系统,但一旦让我们头大了,我想我们也应该修理它了.办法当然是改为三层!前面和后面的就不说了,中间的当然是业务逻辑,具体这一层怎么做,我想这一层才是我们做应用的程序员发挥的地方,各人有各人的做法,我认为要注意的是:1.表示层尽量单薄,只展示数据,现在大多数的WEB框架已经强迫我们这样做了;2层间的接口层(facade层)也要注意不要放置业务逻辑,facade只做转发,要注意service也是一种facade;3数据层只负责数据提取与持久化,不要涉及任何业务逻辑,这一点比较难做到,因为我们一不小心就把业务逻辑放在了DAO或者PO中了. 但如果是先分析业务得出业务对象(domain object), 最后考虑持久化,我想这一点也不难了.千万不要先分析数据库表结构,再考虑是一个表一个对象呢,还是一个表多个对象呢还是多个表一个对象,这样做的话,我只能说两个字"完了".
另外,我还想提醒一下,善用"隐喻",对于得出OO的系统有很大的帮助.

应不应该放要看对业务逻辑的分析,而不是一刀切,我想楼主说的"join操作"也不是指数据库的join, 而是指对象间的关系.

另外这一贴放在这个版面好象不太合适?

这已经是第二个人说这是关系数据库的设计思路了

说实话，对这点我还是有点迷茫
过去我一向认为对一个MIS系统来说
OO的分析方法和过去的从数据库入手的分析方式并没有本质的区别
分析和设计存在并发性，很难有一个标准的流程。
必须要搞清楚的是需要获得哪些信息，而不是需要生成哪些制品。
那么面向对象还是面向过程，只是两种不同的模型。
它们的目的都是要表达那些信息。
分析方法的不同在实际工作结果中造成的区别不大。
最后得到的代码应该极为类似以至于难以看出系统分析的风格。

也许是我在OO的道路上落伍了
至少半年前我是这样认为的

无明兄可不可以给详细的解释一下设计思路的问题呢？

恩，simonliu说的有些道理
但是就我第二个问题不知道你们是怎么解决的呢？
能说说吗？

另外，join操作不是特指表间的操作，是实体间的关系操作
放在DAO中的表现形式就成了SQL中的join了
可能是我前面表述的有问题