论坛首页 入门技术论坛

请问在DAO的设计中DAO调用DAO这种设计是正确的吗?

浏览 5820 次
该帖已经被评为新手帖
作者 正文
   发表时间:2006-12-07  
DAO
在设计DAO时,如果一个DAO操作,比如删除对象a的这个操作,在删除a前需要处理与a相关联的b对象的关联关系,而在删除b时也需要处理与其相关联的c对象的关联关系。
这种情况下,我是否应该在删除a对象的DAO中,调用删除b对象的DAO来删除b,以便自动处理b与c的关系?
如果这样操作是否就引起了DAO之间的混乱?
请问DAO之间相互调用是不是一种正确的设计?
   发表时间:2006-12-07  
呵呵!没有绝对的正确和错误之分,如果这样使用起来方便,业务也需要这样,那也未尝不可啊!
0 请登录后投票
   发表时间:2006-12-07  
带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。
0 请登录后投票
   发表时间:2006-12-07  
Jamsa 写道
带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。

一般来说,持久层之所以复杂是因为业务的复杂导致的,是属于业务层的,
DAO对Service来说都是一些原子级的操作,别让DAO承担太多不属于该层的任务,尽量让其保持简单为好.
而你的要求中可以由Service 使用这些原子操作来实现这些复杂性.
0 请登录后投票
   发表时间:2006-12-08  
一般情况下,层次要分明,职责要明确。
0 请登录后投票
   发表时间:2006-12-08  
一般放在service中好一点
0 请登录后投票
   发表时间:2006-12-08  
一般业务不和dao参合太多
0 请登录后投票
   发表时间:2006-12-08  
自己比较喜欢用最简单的方式完成自己的工作,简单就是美.但就楼主提出的问题我觉得还是放在service层会比较好一点,这样的话各层之间就会各司其值
0 请登录后投票
   发表时间:2006-12-08  
DB or O/R cascade
0 请登录后投票
   发表时间:2006-12-08  
wolfsquare 写道
Jamsa 写道
带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。

一般来说,持久层之所以复杂是因为业务的复杂导致的,是属于业务层的,
DAO对Service来说都是一些原子级的操作,别让DAO承担太多不属于该层的任务,尽量让其保持简单为好.
而你的要求中可以由Service 使用这些原子操作来实现这些复杂性.

说得好.
0 请登录后投票
论坛首页 入门技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics