JAVA设计模式之事务处理

    这样的设计非常适合于DAO中的简单活动，我们项目中的一个小系统也是采用这样的设计方案，但是它不适合于更大规模的应用。首先，你有没有闻到代码重复的 bad smell？每次都要设置AutoCommit为false,然后提交，出现异常回滚，包装异常抛到上层，写多了不烦才怪，那能不能消除呢？其次，业务代表对象现在知道它内部事务管理的所有的细节，这与我们设计业务代表对象的初衷不符。对于业务代表对象来说，了解一个与事务有关的业务约束是相当恰当的，但是让它负责来实现它们就不太恰当了。再次，你是否想过嵌套业务对象的场景？业务代表对象之间的互相调用，层层嵌套，此时你又如何处理呢？你要知道按我们现在的方式，每个业务方法都处于各自独立的事务上下文当中(Transaction Context），互相调用形成了嵌套事务，此时你又该如何处理？也许办法就是重新写一遍，把不同的业务方法集中成一个巨无霸包装在一个事务上下文中。

    我们有更为优雅的设计来解决这类问题，如果我们把Transaction Context的控制交给一个被业务代表对象、DAO和其他Component所共知的外部对象。当业务代表对象的某个方法需要事务管理时，它提示此外部对象它希望开始一个事务，外部对象获取一个连接并且开始数据库事务。也就是将事务控制从service层抽离，当web层调用service层的某个业务代表对象时，返回的是一个经过Transaction Context外部对象包装（或者说代理）的业务对象。此代理对象将请求发送给原始业务代表对象，但是对其中的业务方法进行事务控制。那么，我们如何实现此效果呢？答案是JDK1.3引进的动态代理技术。动态代理技术只能代理接口，这也是为什么我们需要业务接口BookStoreManager的原因。
    首先，我们引入这个Transaction Context外部对象，它的代码其实很简单，如果不了解动态代理技术的请先阅读其他资料。