最近一直在想一个关于事务处理层次 的问题。平时我们在做J2EE应用的时候,习惯把应用分为三个逻辑层次,web层,业务层和持久层,比较经典的 是持久层一般使用dao的设计方式。涉及到数据库相关的事务处理时,很多人也就习惯于将事务处理代码写在dao这一个层次上,也就是持久层这个层次。这样 写对于简单一点的数据库访问没有什么问题,一旦实现复杂一点,牵涉到的业务处理比较繁杂一点时,这种在dao里面处理事务的方法就有点力不从心了。
打个比方,我一个dbDAO接口里面有updateA和updateB两个方法,这两个方法中假设都会同时更新几张表(这种情况很常见),这样就会涉及到 事务处理的问题,在updateA中,我们使用事务进行处理,在updateB中我们也谢了事务处理的语句。现在问题来了,如果一个业务处理要求,如果 updateA成功时,更新updateB,如果失败,那么都需要回滚,这样的话,业务层调用了updateA成功提交之后,updateB却失败了,原 来那个方法就没有办法回滚。当然,我们可以在dao中增加两个没有事务处理的方法来调用,但是请仔细想想,这样合适么?????
不过,你也可以将部分业务实现写到dao中去,这样也可以处理,但是这样业务层和持久层就明显含混不清,失去了分层的意义。
因此我们想到把事务处理放到业务中去。原因很明显,事务处理是业务处理的需要,理应随业务的变化而变化,事务跟底层持久化毫不相干,也就是说dao层根本 不应该出现事务处理的代码。但是如果我们将数据库事务处理代码放到业务层之后,明显感觉有点bad smell的味道。所以我们可以利用AOP框架,例如,SPring,将事务处理单独提炼出来,对业务层进行事务控制。而DAO层由于接收事务处理的任 务,所以任何业务方法都可以放心调用,只有在需要事务的时候对业务方法添加事务即可。