事务处理的层次问题

最近一直在想一个关于事务处理层次 的问题。平时我们在做J2EE应用的时候，习惯把应用分为三个逻辑层次，web层，业务层和持久层，比较经典的是持久层一般使用dao的设计方式。涉及到数据库相关的事务处理时，很多人也就习惯于将事务处理代码写在dao这一个层次上，也就是持久层这个层次。这样写对于简单一点的数据库访问没有什么问题，一旦实现复杂一点，牵涉到的业务处理比较繁杂一点时，这种在dao里面处理事务的方法就有点力不从心了。

   打个比方，我一个dbDAO接口里面有updateA和updateB两个方法，这两个方法中假设都会同时更新几张表（这种情况很常见），这样就会涉及到事务处理的问题，在updateA中，我们使用事务进行处理,在updateB中我们也谢了事务处理的语句。现在问题来了，如果一个业务处理要求，如果updateA成功时，更新updateB，如果失败，那么都需要回滚，这样的话，业务层调用了updateA成功提交之后，updateB却失败了，原来那个方法就没有办法回滚。当然，我们可以在dao中增加两个没有事务处理的方法来调用，但是请仔细想想，这样合适么？？？？？

  不过，你也可以将部分业务实现写到dao中去，这样也可以处理，但是这样业务层和持久层就明显含混不清，失去了分层的意义。

 因此我们想到把事务处理放到业务中去。原因很明显，事务处理是业务处理的需要，理应随业务的变化而变化，事务跟底层持久化毫不相干，也就是说dao层根本不应该出现事务处理的代码。但是如果我们将数据库事务处理代码放到业务层之后，明显感觉有点badsmell的味道。所以我们可以利用AOP框架，例如，SPring,将事务处理单独提炼出来，对业务层进行事务控制。而DAO层由于接收事务处理的任务，所以任何业务方法都可以放心调用，只有在需要事务的时候对业务方法添加事务即可。