JAVA设计模式之事务处理

    事务处理是企业应用需要解决的最主要的问题之一。J2EE通过JTA提供了完整的事务管理能力，包括多个事务性资源的管理能力。但是大部分应用都是运行在单一的事务性资源之上（一个数据库），他们并不需要全局性的事务服务。本地事务服务已然足够(比如JDBC事务管理）。
    本文并不讨论应该采用何种事务处理方式，主要目的是讨论如何更为优雅地设计事务服务。仅以JDBC事务处理为例。涉及到的DAO，Factory,Proxy,Decorator等模式概念，请阅读相关资料。
    也许你听说过，事务处理应该做在service层，也许你也正这样做，但是否知道为什么这样做？为什么不放在DAO层做事务处理。显而易见的原因是业务层接口的每一个方法有时候都是一个业务用例（User Case），它需要调用不同的DAO对象来完成一个业务方法。比如简单地以网上书店购书最后的确定定单为例，业务方法首先是调用BookDAO对象（一般是通过DAO工厂产生），BookDAO判断是否还有库存余量，取得该书的价格信息等，然后调用CustomerDAO从帐户扣除相应的费用以及记录信息，然后是其他服务（通知管理员等）。简化业务流程大概如此:
    注意,我们的例子忽略了连接的处理，只要保证同一个线程内取的是相同的连接即可（可用ThreadLocal实现）：

    首先是业务接口，针对接口，而不是针对类编程：

2. public interface BookStoreManager{
3.           public boolean buyBook(String bookId,int quantity)throws SystemException;
4.           ....其他业务方法
5.     }

    接下来就是业务接口的实现类??业务对象：

2. public class BookStoreManagerImpl implements BookStoreManager{
3.          public boolean buyBook(String bookId)throws SystemException{
4.               Connection conn=ConnectionManager.getConnection();//获取数据库连接
5.               boolean b=false;
6.              
7.               try{
8.                   conn.setAutoCommit(false);  //取消自动提交
9.                   BookDAO bookDAO=DAOFactory.getBookDAO();
10.                   CustomerDAO customerDAO=DAOFactory.getCustomerDAO();
11.                     //尝试从库存中取书
12.                   if(BookDAO.reduceInventory(conn,bookId,quantity)){
13.                        BigDecimal price=BookDAO.getPrice(bookId);  //取价格
14.                        //从客户帐户中扣除price*quantity的费用
15.                        b=
16.                        CustomerDAO.reduceAccount(conn,price.multiply(new BigDecimal(quantity));
17.                        ....
18.                        其他业务方法，如通知管理员，生成定单等.
19.                         ...
20.                        conn.commit();   //提交事务
21.                        conn.setAutoCommit(true);
22.                   }
23.                }catch(SQLException e){
24.                   conn.rollback();   //出现异常，回滚事务
25.                   con.setAutoCommit(true);
26.                   e.printStackTrace();
27.                   throws new SystemException(e);  
28.                }
29.                return b;
30.          }
31.     }

    然后是业务代表工厂：  

2.   public final class ManagerFactory {
3.       public static BookStoreManager getBookStoreManager() {
4.          return new BookStoreManagerImpl();
5.       }
6.    }

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

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

 

[1]  

【责编:Peng】

--------------------next---------------------