|
锁定老帖子 主题：如何设计DAO层
精华帖 (0) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-13
我和你的理解差不多，但是你的主题不是说明这个，应该是是个粒度问题
|
| 返回顶楼 | |
|
发表时间：2006-10-13
hasi 写道 应该是是个粒度问题
粒度？不解，我对粒度还不明白，谁能详细说下？？ |
| 返回顶楼 | |
|
发表时间：2006-10-13
galaxystar 写道 楼上的应该比较熟悉hibernate，一定也在用它开发吧！
做项目追求速度，而对于业务较复杂的（一次性关联4，5张表），你不写SQL，让H去持久，可能问题会比较多！且开发测试效率反而降低！ 我说的粒度细，是指一个DAO方法里只处理一次数据库访问，分页也该分成2个DAO方法！ 另外根据业务去处理，如你所说更新一个状态字段，如果业务需要，且这样设计是可行的，那么就这么做！有什么不对吗?有些场景就是这么做的! 你说service层写sql,那么你根本就没有把整个层次分清楚！如果感觉DAO层简单，那是因为框架强大了，如果什么链接释放，事务提交都让DAO来做，这样就算是DAO层了？ 你说DAO应该是代码生成器搞出来的，那么就是业务层只要操作下对象，SQL配置下，直接就持久了？你认为此类频繁的操作，放业务层合适?DAO最大的理念就是分离业务逻辑与持久代码！ sorry,没说清楚.我的意思是DAO就简单的CRUD,然后service里调用dao进行各种操作. 对于所谓的sql写service,你误解我的意思了.我主要是想问的复杂查询的情况,那么你在DAO中搞一堆sql语句,返回你的数据(比如一个Map),然后service直接调用DAO,再次返回同样的数据,这样做与直接把sql写在service有多大区别.而这种复杂查询以后根本不会重用的. |
| 返回顶楼 | |
|
发表时间：2006-10-14
yfmine 写道 galaxystar 写道 楼上的应该比较熟悉hibernate，一定也在用它开发吧！
做项目追求速度，而对于业务较复杂的（一次性关联4，5张表），你不写SQL，让H去持久，可能问题会比较多！且开发测试效率反而降低！ 我说的粒度细，是指一个DAO方法里只处理一次数据库访问，分页也该分成2个DAO方法！ 另外根据业务去处理，如你所说更新一个状态字段，如果业务需要，且这样设计是可行的，那么就这么做！有什么不对吗?有些场景就是这么做的! 你说service层写sql,那么你根本就没有把整个层次分清楚！如果感觉DAO层简单，那是因为框架强大了，如果什么链接释放，事务提交都让DAO来做，这样就算是DAO层了？ 你说DAO应该是代码生成器搞出来的，那么就是业务层只要操作下对象，SQL配置下，直接就持久了？你认为此类频繁的操作，放业务层合适?DAO最大的理念就是分离业务逻辑与持久代码！ sorry,没说清楚.我的意思是DAO就简单的CRUD,然后service里调用dao进行各种操作. 对于所谓的sql写service,你误解我的意思了.我主要是想问的复杂查询的情况,那么你在DAO中搞一堆sql语句,返回你的数据(比如一个Map),然后service直接调用DAO,再次返回同样的数据,这样做与直接把sql写在service有多大区别.而这种复杂查询以后根本不会重用的. DAO就简单的CRUD?那比如说GROUP与USER两个对象两张表,中间一张关联表USERTOGOUP.你怎么处理它们之间的关系,在service中吗?为什么不可以在dao中一个sql搞定呢?效率又高.虽然不OO,但又有什么关系呢? |
| 返回顶楼 | |
|
发表时间：2006-10-15
赞同楼上的，sql的关联查询是非常强大的，有函数，存储过程的支持！这些问题是很好解决的！
|
| 返回顶楼 | |
|
发表时间：2006-10-15
如果你知道你做的事情，三层足够了，否则7层也没有用。
推荐一个类，包含所有的方法，使用简单参数。这样修改方便。别被OO束缚了。 |
| 返回顶楼 | |
|
发表时间：2006-10-18
ronghao 写道 DAO就简单的CRUD?那比如说GROUP与USER两个对象两张表,中间一张关联表USERTOGOUP.你怎么处理它们之间的关系,在service中吗?为什么不可以在dao中一个sql搞定呢?效率又高.虽然不OO,但又有什么关系呢? 既然要这样,何必再写到DAO里去,对于这些特定的东西,直接写在Service里不就行了.偏要去搞个所谓的"DAO层",然后Service的方法就只是直接调用DAO?我几时说一定要OO了,我的意思是可以减少不必要的层.加入复杂的东西到DAO后,DAO就可能隐含了某些业务逻辑.既然这样,何不直接写在Service里,与写在DAO有什么区别,还更简单. |
| 返回顶楼 | |
|
发表时间：2006-10-18
yfmine 写道 ronghao 写道 DAO就简单的CRUD?那比如说GROUP与USER两个对象两张表,中间一张关联表USERTOGOUP.你怎么处理它们之间的关系,在service中吗?为什么不可以在dao中一个sql搞定呢?效率又高.虽然不OO,但又有什么关系呢? 既然要这样,何必再写到DAO里去,对于这些特定的东西,直接写在Service里不就行了.偏要去搞个所谓的"DAO层",然后Service的方法就只是直接调用DAO?我几时说一定要OO了,我的意思是可以减少不必要的层.加入复杂的东西到DAO后,DAO就可能隐含了某些业务逻辑.既然这样,何不直接写在Service里,与写在DAO有什么区别,还更简单. 逻辑不是很复杂的话,DAO和Service层直接写成一个,这个没错.问题是:当你的业务比较复杂时,是可以把部分逻辑能够用sql直接描述出来的扔到DAO层中的.DAO层没必要那么简洁吧.如果DAO就简单的CRUD,你觉得它还有存在的必要吗? |
| 返回顶楼 | |
|
发表时间：2006-10-19
ronghao 写道 逻辑不是很复杂的话,DAO和Service层直接写成一个,这个没错.问题是:当你的业务比较复杂时,是可以把部分逻辑能够用sql直接描述出来的扔到DAO层中的.DAO层没必要那么简洁吧.如果DAO就简单的CRUD,你觉得它还有存在的必要吗?
OK,基本达成共识,我说的就是没必要搞复杂DAO的情况. PS:对于业务逻辑比较复杂时,也可以调用简单的DAO来实现复杂的逻辑.直接使用sql难以测试,调试,修改,更难以移植.当然,仅仅是业务复杂而已,如果数据量也很大,那还不如用存储过程来实现了.无所谓什么好的设计,一切只为了程序实现功能,简洁,易懂,易修改.这个陈词滥调的设计问题不敢再讨论下去了,看各位的隐藏票就能看出来... 
很奇怪的是这个隐藏帖我怎么还能看到,难道是因为我回复过? |
| 返回顶楼 | |
|
发表时间：2006-10-19
一个项目的解决方案
针对一个表写两个Dao 1 com.yyy.XXDao (不关联其他表的数据库操作) 2 com.yyy.buessniss.XXDao （关联其他表的数据库操作） |
| 返回顶楼 | |
