关于层的问题,高手指教

[Netself]

我现在做的项目是分层的: 表现层,业务层,持久层
有人说把事务写在业务层.
我很不理解, 不是业务层只写业务逻辑吗?
持久层才与事务有关啊,应该怎么实现事务在业务层?
请高手指点迷津.
先谢了.

[天涯倦客]

解析业务流程.

[Netself]

来点详细地

[碧海情天-赵亮]

凡事不可着相，不可执着。并且不可没有自己的思考主张而只听别人的。
自己的思考主张，来源于对知识的积累理解。

[hbwhwang]

你对业务层和持久层的划分界限没搞清楚。
持久层就是简单地操作数据库，可能每个表对应一个DAO
某事务（业务层的某个方法）可能包括对多个表（dao）的操作，因此把事务放到DAO是不妥当的。
当然，如果你没有复杂的事务，连业务层都不需要，那么就无所谓了

[bingxue2332]

在分一层出来作为事务的代理层

不需要拘泥在多少层的问题上

[cuiyingfeng]

我想搂主理解的事务应该是数据库的事务吧，所以说只以为它与持久层相关了。

业务层的事务借用持久层事务的概念，着重其动作的原子性，即不可分割，比如一个业务层事务包含多次数据库操作，甚至可能是对多个数据库的操作，也许在该事务内部还有对其他业务的处理，这些操作和处理必须被看成一个整体，要么全部执行，要么一个不做。所以业务像数据库一样，也有自己的事务。

[RamboAndGates]

transaction控制应该放在业务层。

[Netself]

cyfnjtu(迎风) ( ) 信誉：100 Blog 2006-11-08 09:08:00 得分: 0


我想搂主理解的事务应该是数据库的事务吧，所以说只以为它与持久层相关了。

业务层的事务借用持久层事务的概念，着重其动作的原子性，即不可分割，比如一个业务层事务包含多次数据库操作，甚至可能是对多个数据库的操作，也许在该事务内部还有对其他业务的处理，这些操作和处理必须被看成一个整体，要么全部执行，要么一个不做。所以业务像数据库一样，也有自己的事务。
=============================================================================
谢谢迎风大侠,你说的对我的确把事务理解成数据库的事务啦.
还是有点不明白如果业务层中的一个事务里有多个业务逻辑都操作数据库,当一个业务逻辑完成数据库操作后,而在后面的业务逻辑执行时出了问题,所以这个事务就要回滚对吧.但第一个业务逻辑已经操作完数据库拉啊.怎么才能把对数据库的操作事务也回滚呢.
可能我理解的不对,请大侠细解?

[GODProbe]

你说的事务应该是业务逻辑事务，根据业务逻辑界定的事务，很可能涉及数张表，被业务逻辑决定的事务最好是写在业务层。
而且业务层也不仅仅有业务逻辑事务，涉及PO状态改变的持久化操作也可以写在业务层。面向对象的PO内部只有不涉及持久化的状态设置方法，特别是有关联的时候，这个PO调用另一个PO的DAO的方法，你说这种结构不糟糕吗？

[yun15291li]

我想可以这样想：
lz所说的事务是技术范围的事务，或者说更是数据库方面的事务。

如果从业务角度分析，是不是会分析出，这两件事必须是一个事务，而这不是要想到数据库如何操作上的，这是业务层应该分析的事儿。

这是一个思路的问题。

不过现在或者说已经争议很久的问题，就是pojo（简单对象层）应该不应该写业务逻辑代码。就是所谓的失血、贫血、充血 领域模型问题。或者看看这方面会对lz有一些启示，其中好坏也只有自己去体会评说。