设计模式之事务处理

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

    首先是业务接口,针对接口,而不是针对类编程:
ExpandedBlockStart.gifpublic interface BookStoreManager{
InBlock.gif          public boolean buyBook(String bookId,int quantity)throws SystemException;
InBlock.gif          dot.gif.其他业务方法
ExpandedBlockEnd.gif}

None.gif

    接下来就是业务接口的实现类——业务对象:
ExpandedBlockStart.gif   public class BookStoreManagerImpl implements BookStoreManager{
ExpandedSubBlockStart.gif         public boolean buyBook(String bookId)throws SystemException{
InBlock.gif              Connection conn=ConnectionManager.getConnection();//获取数据库连接
InBlock.gif
              boolean b=false;
InBlock.gif              
ExpandedSubBlockStart.gif              try{
InBlock.gif                  conn.setAutoCommit(false);  //取消自动提交
InBlock.gif
                  BookDAO bookDAO=DAOFactory.getBookDAO();
InBlock.gif                  CustomerDAO customerDAO=DAOFactory.getCustomerDAO();
InBlock.gif                    //尝试从库存中取书 
ExpandedSubBlockStart.gif
                  if(BookDAO.reduceInventory(conn,bookId,quantity)){
InBlock.gif                       BigDecimal price=BookDAO.getPrice(bookId);  //取价格
InBlock.gif                       
//从客户帐户中扣除price*quantity的费用
InBlock.gif
                       b=
InBlock.gif                       CustomerDAO.reduceAccount(conn,price.multiply(new BigDecimal(quantity));
InBlock.gif                       dot.gif.
InBlock.gif                       其他业务方法,如通知管理员,生成定单等.
InBlock.gif                        dot.gif
InBlock.gif                       conn.commit();   //提交事务
InBlock.gif
                       conn.setAutoCommit(true);
ExpandedSubBlockEnd.gif                  }

ExpandedSubBlockStart.gif               }
catch(SQLException e){
InBlock.gif                  conn.rollback();   //出现异常,回滚事务
InBlock.gif
                  con.setAutoCommit(true);
InBlock.gif                  e.printStackTrace();
InBlock.gif                  throws new SystemException(e);   
ExpandedSubBlockEnd.gif               }

InBlock.gif               return b;
ExpandedSubBlockEnd.gif         }
 
ExpandedBlockEnd.gif    }

None.gif
 
    然后是业务代表工厂:
  
ExpandedBlockStart.gif public final class ManagerFactory {
ExpandedSubBlockStart.gif      public static BookStoreManager getBookStoreManager() {
InBlock.gif         return new BookStoreManagerImpl();
ExpandedSubBlockEnd.gif      }

ExpandedBlockEnd.gif   }

None.gif


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

    我们有更为优雅的设计来解决这类问题,如果我们把Transaction Context的控制交给一个被业务代表对象、DAO和其他Component所共知的外部对象。当业务代表对象的某个方法需要事务管理时,它提示此外部对象它希望开始一个事务,外部对象获取一个连接并且开始数据库事务。也就是将事务控制从service层抽离,当web层调用service层的某个业务代表对象时,返回的是一个经过Transaction Context外部对象包装(或者说代理)的业务对象。此代理对象将请求发送给原始业务代表对象,但是对其中的业务方法进行事务控制。那么,我们如何实现此效果呢?答案是JDK1.3引进的动态代理技术。动态代理技术只能代理接口,这也是为什么我们需要业务接口BookStoreManager的原因。
    首先,我们引入这个Transaction Context外部对象,它的代码其实很简单,如果不了解动态代理技术的请先阅读其他资料。
None.gifimport java.lang.reflect.InvocationHandler;
None.gifimport java.lang.reflect.Method;
None.gifimport java.lang.reflect.Proxy;
None.gif
None.gifimport java.sql.Connection;
None.gif
None.gifimport com.strutslet.demo.service.SystemException;
None.gif
ExpandedBlockStart.gifpublic final class TransactionWrapper {
InBlock.gif
ExpandedSubBlockStart.gif    /**
InBlock.gif     * 装饰原始的业务代表对象,返回一个与业务代表对象有相同接口的代理对象 
ExpandedSubBlockEnd.gif     
*/

ExpandedSubBlockStart.gif    public static Object decorate(Object delegate) {
InBlock.gif        return Proxy.newProxyInstance(delegate.getClass().getClassLoader(),
InBlock.gif                delegate.getClass().getInterfaces(), new XAWrapperHandler(
InBlock.gif                        delegate));
ExpandedSubBlockEnd.gif    }

InBlock.gif    
InBlock.gif    //动态代理技术
ExpandedSubBlockStart.gif
    static final class XAWrapperHandler implements InvocationHandler {
InBlock.gif        private final Object delegate;
InBlock.gif
ExpandedSubBlockStart.gif        XAWrapperHandler(Object delegate) {
InBlock.gif           this.delegate = delegate;
ExpandedSubBlockEnd.gif        }

InBlock.gif        
InBlock.gif        //简单起见,包装业务代表对象所有的业务方法
InBlock.gif
        public Object invoke(Object proxy, Method method, Object[] args)
ExpandedSubBlockStart.gif                throws Throwable {
InBlock.gif            Object result = null;
InBlock.gif            Connection con = ConnectionManager.getConnection();
ExpandedSubBlockStart.gif            try 
InBlock.gif                //开始一个事务
InBlock.gif
                con.setAutoCommit(false);
InBlock.gif                //调用原始业务对象的业务方法
InBlock.gif
                result = method.invoke(delegate, args);
InBlock.gif                con.commit();   //提交事务
InBlock.gif
                con.setAutoCommit(true);
ExpandedSubBlockStart.gif            }
 catch (Throwable t) {
InBlock.gif                //回滚
InBlock.gif
                con.rollback();
InBlock.gif                con.setAutoCommit(true);
InBlock.gif                throw new SystemException(t);
ExpandedSubBlockEnd.gif            }

InBlock.gif
InBlock.gif            return result;
ExpandedSubBlockEnd.gif        }

ExpandedSubBlockEnd.gif    }

ExpandedBlockEnd.gif}

None.gif

    正如我们所见,此对象只不过把业务对象需要事务控制的业务方法中的事务控制部分抽取出来而已。请注意,业务代表对象内部调用自身的方法将不会开始新的事务,因为这些调用不会传给代理对象。如此,我们去除了代表重复的味道。此时,我们的业务代表对象修改成:
ExpandedBlockStart.gifpublic class BookStoreManagerImpl implements BookStoreManager {
ExpandedSubBlockStart.gif    public boolean buyBook(String bookId)throws SystemException{
InBlock.gif          Connection conn=ConnectionManager.getConnection();// 获取数据库连接
InBlock.gif
          boolean b=false;
ExpandedSubBlockStart.gif          try{
InBlock.gif              BookDAO bookDAO=DAOFactory.getBookDAO();
InBlock.gif              CustomerDAO customerDAO=DAOFactory.getCustomerDAO();
InBlock.gif              // 尝试从库存中取书
ExpandedSubBlockStart.gif
              if(BookDAO.reduceInventory(conn,bookId,quantity)){
InBlock.gif                  BigDecimal price=BookDAO.getPrice(bookId);  // 取价格
InBlock.gif                  
// 从客户帐户中扣除price*quantity的费用
InBlock.gif
                  b=
InBlock.gif                  CustomerDAO.reduceAccount(conn,price.multiply(new BigDecimal(quantity));
InBlock.gif                  dot.gif.
InBlock.gif                  其他业务方法,如通知管理员,生成定单等.
InBlock.gif                  dot.gif
ExpandedSubBlockEnd.gif              }

ExpandedSubBlockStart.gif          }
catch(SQLException e){
InBlock.gif             throws new SystemException(e);
ExpandedSubBlockEnd.gif          }

InBlock.gif          return b;
ExpandedSubBlockEnd.gif    }

InBlock.gif    dot.gif
ExpandedBlockEnd.gif}

None.gif

    可以看到,此时的业务代表对象专注于实现业务逻辑,它不再关心事务控制细节,把它们全部委托给了外部对象。业务代表工厂也修改一下,让它返回两种类型的业务代表对象:
  
ExpandedBlockStart.gif public final class ManagerFactory {
InBlock.gif      //返回一个被包装的对象,有事务控制能力
ExpandedSubBlockStart.gif
      public static BookStoreManager getBookStoreManagerTrans() {
InBlock.gif          return (BookStoreManager) TransactionWrapper
InBlock.gif                  .decorate(new BookStoreManagerImpl());
ExpandedSubBlockEnd.gif      }

InBlock.gif      //原始版本
ExpandedSubBlockStart.gif
      public static BookStoreManager getBookStoreManager() {
InBlock.gif         return new BookStoreManagerImpl();
ExpandedSubBlockEnd.gif      }

InBlock.gif      dot.gifdot.gif
ExpandedBlockEnd.gif   }

None.gif
   
   我们在业务代表工厂上提供了两种不同的对象生成方法:一个用于创建被包装的对象,它会为每次方法调用创建一个新的事务;另外一个用于创建未被包装的版本,它用于加入到已有的事务(比如其他业务代表对象的业务方法),解决了嵌套业务代表对象的问题。 

   我们的设计还不够优雅,比如我们默认所有的业务代表对象的方法调用都将被包装在一个Transaction Context。可事实是很多方法也许并不需要与数据库打交道,如果我们能配置哪些方法需要事务声明,哪些不需要事务管理就更完美了。解决办法也很简单,一个XML配置文件来配置这些,调用时判断即可。说到这里,了解spring的大概都会意识到这不正是声明式事务控制吗?正是如此,事务控制就是AOP的一种服务,spring的声明式事务管理是通过AOP实现的。AOP的实现方式包括:动态代理技术,字节码生成技术(如CGLIB库),java代码生成(早期EJB采用),修改类装载器以及源代码级别的代码混合织入(aspectj)等。我们这里就是利用了动态代理技术,只能对接口代理;对类的动态代理可以使用cglib库。


文章转自庄周梦蝶  ,原文发布时间2007-02-06

目录
相关文章
|
7月前
|
设计模式 前端开发 算法
设计模式之设计原则
程序设计的要遵循的一些理论,也可以理解为程序设计的一种要求和目标,是面向对象程序设计的基石,也是面向对象程序设计的质量保障和依据。
39 0
|
4月前
|
设计模式 关系型数据库 程序员
【设计模式】设计原则
【1月更文挑战第12天】【设计模式】设计原则
|
4月前
|
设计模式 存储 前端开发
【设计模式】之调停者模式
调停者模式是一种有助于降低对象之间耦合度的设计模式。它通过引入一个调停者对象来集中处理一组对象之间的交互,使得代码更易于维护和扩展。在前端开发中,调停者模式可以应用于表单验证、消息订阅与发布、组件间通信等场景。尽管调停者模式可能会增加系统的复杂性,并且调停者对象可能变得庞大和复杂,但它仍然是一种有价值的设计模式,可以提高代码的可读性和可维护性。
41 0
【设计模式】之调停者模式
|
5月前
|
设计模式 程序员
设计模式-设计原则
设计模式-设计原则
|
11月前
|
设计模式
设计模式总结(四):设计原则
设计模式总结(四):设计原则
58 0
|
存储 设计模式 NoSQL
分布式系统设计模式,你用过哪些?(2)
分布式系统设计模式,你用过哪些?
104 0
|
消息中间件 机器学习/深度学习 设计模式
分布式系统设计模式,你用过哪些?(1)
分布式系统设计模式,你用过哪些?
111 0
|
设计模式 PHP
设计模式中设计原则
延迟静态绑定 self 用于类中静态 this 用于对象中静态 static 延迟绑定用于对象中实例化本类 parent 用于父级元素 高内聚,低耦合 耦合:多个组合、多个类。 内聚:重复代码。 组合优于继承,针对接口编程,变化的概念,父子关系
77 0
|
设计模式 前端开发 Unix
设计模式之设计原则(2)
设计模式之设计原则(2)
91 0
|
设计模式 Java 关系型数据库
设计模式之七大设计原则详解
设计模式之七大设计原则详解
651 0
设计模式之七大设计原则详解