正如我们所见，此对象只不过把业务对象需要事务控制的业务方法中的事务控制部分抽取出来而已。请注意，业务代表对象内部调用自身的方法将不会开始新的事务，因为这些调用不会传给代理对象。如此，我们去除了代表重复的味道。此时，我们的业务代表对象修改成：
-
- public class BookStoreManagerImpl implements BookStoreManager {
- public boolean buyBook(String bookId)throws SystemException{
- Connection conn=ConnectionManager.getConnection();// 获取数据库连接
- boolean b=false;
- try{
- BookDAO bookDAO=DAOFactory.getBookDAO();
- CustomerDAO customerDAO=DAOFactory.getCustomerDAO();
- // 尝试从库存中取书
- if(BookDAO.reduceInventory(conn,bookId,quantity)){
- BigDecimal price=BookDAO.getPrice(bookId); // 取价格
- // 从客户帐户中扣除price*quantity的费用
- b=
- CustomerDAO.reduceAccount(conn,price.multiply(new BigDecimal(quantity));
- ....
- 其他业务方法，如通知管理员，生成定单等.
- ...
- }
- }catch(SQLException e){
- throws new SystemException(e);
- }
- return b;
- }
- ....
- }
可以看到，此时的业务代表对象专注于实现业务逻辑，它不再关心事务控制细节，把它们全部委托给了外部对象。业务代表工厂也修改一下，让它返回两种类型的业务代表对象：
-
- public final class ManagerFactory {
- //返回一个被包装的对象，有事务控制能力
- public static BookStoreManager getBookStoreManagerTrans() {
- return (BookStoreManager) TransactionWrapper
- .decorate(new BookStoreManagerImpl());
- }
- //原始版本
- public static BookStoreManager getBookStoreManager() {
- return new BookStoreManagerImpl();
- }
- ......
- }
我们在业务代表工厂上提供了两种不同的对象生成方法：一个用于创建被包装的对象，它会为每次方法调用创建一个新的事务；另外一个用于创建未被包装的版本，它用于加入到已有的事务(比如其他业务代表对象的业务方法)，解决了嵌套业务代表对象的问题。
我们的设计还不够优雅，比如我们默认所有的业务代表对象的方法调用都将被包装在一个Transaction Context。可事实是很多方法也许并不需要与数据库打交道，如果我们能配置哪些方法需要事务声明，哪些不需要事务管理就更完美了。解决办法也很简单，一个XML配置文件来配置这些，调用时判断即可。说到这里，了解spring的大概都会意识到这不正是声明式事务控制吗？正是如此，事务控制就是AOP的一种服务，spring的声明式事务管理是通过AOP实现的。AOP的实现方式包括：动态代理技术，字节码生成技术（如CGLIB库），java代码生成（早期EJB采用），修改类装载器以及源代码级别的代码混合织入（aspectj)等。我们这里就是利用了动态代理技术，只能对接口代理；对类的动态代理可以使用cglib库。
这篇短文只是介绍下我对事务上下文模式以及声明式事务管理实现基本原理的理解，如有错误，请不吝赐教，谢谢。我的email:killme2008@gmail.com
京公网安备 11010802021500号