|
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-08
DAO 调用DAO 那你事物在哪里控制?
|
| 返回顶楼 | |
|
发表时间：2006-12-08
dao一般只是一些数据库得最基本得一些操作i u s d，
复杂得逻辑可以在service通过对dao得调用来实现 通过service得配置，可以保证一个service得事务完整性 写在逻辑写在dao里面不太好，这样得话也根本没有必要用dao模式勒 |
| 返回顶楼 | |
|
发表时间：2006-12-09
我个人也觉得数据访问应该保持简单，并保持各个DAO的独立性。
但如果放在逻辑层，这种逻辑并非业务上的逻辑，而只是在使用Hibernate作数据访问层时才出现的问题。 现在我有个想法，利用Hibernate的事件机制来处理这种问题，正在实验中。 |
| 返回顶楼 | |
|
发表时间：2006-12-09
ASDF1982 写道 DAO 调用DAO 那你事物在哪里控制?
这个跟DAO调DAO没什么关系吧，我现在用的事务控制都是PROPAGATION_REQUIRED |
| 返回顶楼 | |
|
发表时间：2006-12-09
lighter 写道 wolfsquare 写道 Jamsa 写道 带来的方便就是在业务层不再需要理解持久层对象之间复杂的关联关系。
一般来说,持久层之所以复杂是因为业务的复杂导致的,是属于业务层的, DAO对Service来说都是一些原子级的操作,别让DAO承担太多不属于该层的任务,尽量让其保持简单为好. 而你的要求中可以由Service 使用这些原子操作来实现这些复杂性. 说得好.  DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD啊 |
| 返回顶楼 | |
|
发表时间：2006-12-10
兄弟你有救了...
serivce的出现,就是为了解决你的问题... |
| 返回顶楼 | |
|
发表时间：2006-12-10
raykcn 写道 兄弟你有救了...
serivce的出现,就是为了解决你的问题... 我所说的是解决如二级缓存管理的这种问题，这也属于业务逻辑吗？ |
| 返回顶楼 | |
