数据持久层.

事务管理持久层封装

JDBC

Hibernate in Spring

ibatis in Spring

[@more@]对于J2EE 应用程序而言，事务的处理一般有两种模式： 1． 依赖特定事务资源的事务处理这是应用开发中最常见的模式，即通过特定资源提供的事务机制进行事务管理。如通过JDBC、JTA 的rollback、commit方法；Hibernate Transaction 的 rollback、commit方法等。这种方法大家已经相当熟悉。 2． 依赖容器的参数化事务管理通过容器提供的集约式参数化事务机制，实现事务的外部管理，如EJB 中的事务管理模式。 配置中包含了dataSource，transactionManager 等资源定义。这些资源都为一个名为userDAOProxy 的TransactionProxyFactoryBean 服务， 而 userDAOProxy 则对包含实际数据逻辑的userDAO进行了事务性封装。 Spring事务管理能给我们带来什么? 对于传统的基于特定事务资源的事务处理而言（如基于JDBC 的数据库访问）， Spring并不会对其产生什么影响，我们照样可以成功编写并运行这样的代码。同时，对于依赖容器的参数化事务管理而言，Spring 则表现出了极大的价值。Spring 本身也是一个容器，只是相对EJB容器而言，Spring显得更为轻便小巧。我们无需付出其他方面的代价，即可通过Spring实现基于容器的事务管理（本质上来讲，Spring 的事务管理是基于动态AOP）。下面这段xml配置片断展示了Spring中的事务设定方式： org.gjt.mm.mysql.Driver jdbc:mysql://localhost/sample user mypass PROPAGATION_REQUIRED PROPAGATION_REQUIRED,readOnly 配置中包含了dataSource，transactionManager 等资源定义。这些资源都为一个名为userDAOProxy 的TransactionProxyFactoryBean 服务， 而 userDAOProxy 则对包含实际数据逻辑的userDAO进行了事务性封装。 结合上面这段申明带来的感性认知，看看Spring 的事务管理机制与EJB 中事务管理有何不同，或者有何优势。这里自然有许多方面可以比较，不过，笔者认为其中最为关键的两点是： 1． Spring可以将任意Java Class 纳入事务管理这里的UserDAO只是我们编写的一个普通Java Class，其中包含了一些基本的数据应用逻辑。通过Spring，我们即可简单的实现事务的可配置化。也就是说，我们可以随意为某个类的某个方法指定事务管理机制。与之对比，如果使用EJB容器提供的事务管理功能，我们不得不按照EJB 规范编将UserDAO 进行改造，将其转换为一个标准的EJB。 2． Spring事务管理并不依赖特定的事务资源。 EJB 容器必须依赖于JTA 提供事务支持。而Spring 的事务管理则支持 JDBC、JTA 等多种事务资源。这为我们提供了更多的选择，从而也使得我们的系统部署更加灵活。 Spring对JDBC进行了良好的封装，通过提供相应的模板和辅助类，在相当程度上降低了JDBC操作的复杂性。并且得益于Spring良好的隔离设计，JDBC封装类库可以脱离 Spring Context独立使用，也就是说，即使系统并没有采用Spring作为结构性框架，也可以单独使用Spring的JDBC部分（spring-dao.jar）来改善我们的代码。