该帖已经被评为新手帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-12-07
这种情况下,我是否应该在删除a对象的DAO中,调用删除b对象的DAO来删除b,以便自动处理b与c的关系? 如果这样操作是否就引起了DAO之间的混乱? 请问DAO之间相互调用是不是一种正确的设计? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-12-07
呵呵!没有绝对的正确和错误之分,如果这样使用起来方便,业务也需要这样,那也未尝不可啊!
|
|
返回顶楼 | |
发表时间:2006-12-07
带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。
|
|
返回顶楼 | |
发表时间:2006-12-07
Jamsa 写道 带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。
一般来说,持久层之所以复杂是因为业务的复杂导致的,是属于业务层的, DAO对Service来说都是一些原子级的操作,别让DAO承担太多不属于该层的任务,尽量让其保持简单为好. 而你的要求中可以由Service 使用这些原子操作来实现这些复杂性. |
|
返回顶楼 | |
发表时间:2006-12-08
一般情况下,层次要分明,职责要明确。
|
|
返回顶楼 | |
发表时间:2006-12-08
一般放在service中好一点
|
|
返回顶楼 | |
发表时间:2006-12-08
一般业务不和dao参合太多
|
|
返回顶楼 | |
发表时间:2006-12-08
自己比较喜欢用最简单的方式完成自己的工作,简单就是美.但就楼主提出的问题我觉得还是放在service层会比较好一点,这样的话各层之间就会各司其值
|
|
返回顶楼 | |
发表时间:2006-12-08
DB or O/R cascade
|
|
返回顶楼 | |
发表时间:2006-12-08
wolfsquare 写道 Jamsa 写道 带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。
一般来说,持久层之所以复杂是因为业务的复杂导致的,是属于业务层的, DAO对Service来说都是一些原子级的操作,别让DAO承担太多不属于该层的任务,尽量让其保持简单为好. 而你的要求中可以由Service 使用这些原子操作来实现这些复杂性. 说得好. |
|
返回顶楼 | |