spring DAO

Spring 数据访问(DAO层) 总结

统一的异常体系

Spring本质上希望以统一的方式整合底层的持久化技术:以统一的方式进行调用及事务管理,避免让具体的实现侵入到业务层的代码中。由于每个持久化实现技术都有各自的异常体系,所以Spring提供了统一的异常体系,使不同异常体系的阻抗得以弥消,方便定义出和具体实现技术无关的DAO接口,以及整合到相同的事务管理体系中。

DAO(Data Access Object)是用于访问数据的对象,统一的异常体系是整合不同的持久化实现技术的关键,Spring面向DAO制定了一个通用的异常体系,这是一套和实现技术无关的、面向于DAO层次语义的异常体系,它屏蔽具体持久化技术的异常,通过转换器将不同的持久化技术异常转换成Spring的异常,使业务层和具体的持久化技术达到解耦。

DAO层的抽象:

 

 

Spring的DAO异常体系:

Spring在org.springframework.dao包中提供了一套完备优雅的DAO异常体系,这些异常都继承于 DataAccessException,而DataAccessException本身又继承于 NestedRuntimeException,NestedRuntimeException异常以嵌套的方式封装了源异常。因为虽然不同持久化技术的特定异常被转换到Spring的DAO异常体系中,原始的异常信息并不会丢失,只要你愿意,就可以方便地通过getCause()方法获取原始的异常信息。在JDBC中的SQLException 中,你必须通过异常的getErrorCode()或getSQLState()获取错误代码,直接根据这些代码判断是错误的类型,这种过于底层的API 不但带来了代码编写上的难度,而且也使代码的移植变得困难,因为getErrorCode()是数据库相关的。 Spring以分类手法建立了异常分类目录,对于大部分应用来说,这个异常分类目录对异常类型的划分具有适当的颗粒度。一方面,使开发者从底层细如针麻的技术细节中脱身出来,另一方面,可以从这个语义丰富的异常体系中选择感兴趣的异常加以处理。

为了进一步细化错误的问题域,Spring对一级异常类进行子类的细分,如InvalidDataAccessResourceUsageException就拥有10多个子类。对于InvalidDataAccessResourceUsageException异常,不同的持久化实现技术均有对应的子异常类。如 BadSqlGrammarException对应JDBC实现技术SQL语句语法错误的异常,而HibernateQueryExcpetion和 TopLinkQueryException分别对应Hibernate和TopLink实现技术的查询语法异常。 Spring的这个异常体系具有高度的可扩展性,当Spring需要对一个新的持久化技术提供支持时,只要定义为其定义一个对应的子异常就可以了,这种更改完全满足设计模式中的开-闭原则。

各ORM持久化技术异常转换器:

统一的数据访问模板

JDBC数据访问操作按以下的流程进行: 
1. 准备资源; 
2. 启动事务; 
3. 在事务中执行具体数据访问操作; 
4. 返回数据; 
5. 提交/回滚事务; 
6. 关闭资源,处理异常。

按照传统的方式,编写任何带事务的数据访问的程序时,你都需要重复编写上面的代码,而其中步骤③的代码是业务相关的。Spring 将这个相同的数据访问流程固化到模板类中,并将数据访问中固定和变化的部分分开,同时保证模板类是线程安全,以便多个数据访问线程共享同一模板实例。固定的部分在模板类中已经准备好,而变化的部分通过回调接口开放出来,用于定义具体数据访问和结果返回的操作。

下图描述了模板类是如何拆分固定和变化部分的逻辑(Spring DAO模板和回调):

Spring为不同持久化技术所提供的模板类 :

如果我们直接使用模板类,一般都需要在DAO中定义一个模板对象并提供数据资源,Spring为每一个持久化技术都提供了支持类,支持类中已经为我们完成这样的功能。 这些支持类都继承于dao.support.DaoSupport类,DaoSupport实现了InitializingBean接口,在afterPropertiesSet()接口方法中检查模板对象和数据源是否被正确设置,否则将抛出异常。 所有的支持类都是abstract的,其目的是希望被继承使用,而非直接使用。这样,我们只需要扩展这些支持类就可以直接编写实际的数据访问逻辑。

不同持久化技术的支持类:

统一的事务管理

JDBC事务代码:

事务模板已经帮我们封装了那些重复的代码。

统一的事务抽象:

Spring 为事务管理提供了一致的编程模板,在高层次建立了统一的事务抽象。也就是说,不管选择Spring JDBC、Hibernate 、JPA 还是iBatis,Spring都让我们可以用统一的编程模型进行事务管理:

  • TransactionDefinition用于描述事务的隔离级别、超时时间、是否为只读事务和事务传播规则等控制事务具体行为的事务属性,这些事务属性可以通过XML配置或注解描述提供,也可以通过手工编程的方式设置。
  • PlatformTransactionManager根据TransactionDefinition提供的事务属性配置信息,创建事务,并用TransactionStatus(继承于SavepointManager接口)描述这个激活事务的状态(事务savepoint、事务是否结束等)。

混合数据访问技术框架所对应的事务管理器:

如果你采用了一个高端ORM技术(Hibernate、JPA、JDO),同时采用一个JDBC技术(Spring JDBC、iBatis),由于前者的会话(Session)是对后者连接(Connection)的封装,Spring会“足够智能地”在同一个事务线程让前者的会话封装后者的连接。所以,我们只要直接采用前者的事务管理器就可以了。

注意问题:使用Hibernate事务管理器后,可以混合使用Hibernate和SpringJDBC数据访问技术,它们将工作于同一事务上下文中。但是使用SpringJDBC访问数据时,Hibernate的一级或二级缓存得不到同步,此外,一级缓存延迟数据同步机制可能会覆盖SpringJDBC数据更改的结果。 由于混合数据访问技术方案存在“事务同步而缓存不同步”的情况,所以最好用Hibernate进行读写操作,而只用SpringJDBC进行读操作。如用Spring JDBC进行简要列表的查询,而用Hibernate对查询出的数据进行维护。 如果确实要同时使用Hibernate和Spring JDBC读写数据,则必须充分考虑到Hibernate缓存机制引发的问题:必须整体分析数据维护逻辑,根据需要及时调用Hibernate的flush()方法,以免覆盖Spring JDBC的更改,在Spring JDBC更改数据库时,维护Hibernate的缓存。由于方法调用顺序的不同都可能影响数据的同步性,因此很容易发生问题,这会极大提高数据访问程序的复杂性。

事务同步管理器:

Spring将JDBC的Connection、Hibernate的Session等访问数据库的连接或会话对象统称为资源(有状态),这些资源在同一时刻是不能多线程共享的,为了让Dao、Service类可能做到singleton(在Spring中,DAO和Service都以单实例的方式存在),Spring的事务同步管理器类org.springframework.transaction.support.TransactionSynchronizationManager使用ThreadLocal为不同事务线程提供了独立的资源副本,将有状态的变量(如Connection等)本地线程化,在本地线程维护事务配置的属性和运行状态信息,将有状态的对象无状态化,实现线程安全。

Spring事务使用:

1、编程式事务管理

2、使用XML配置声明式事务

3、使用注解配置声明式事务:

基于注解的事务配置是使用AOP代理实现的(详见Spring AOP原理):Spring的数据库事务是在动态代理进入到一个invoke方法里面的,然后判断是否需要拦截方法,需要的时候才根据注解和配置生成数据库事务切面上下文。

Spring事务使用AOP代理后的方法调用执行流程:

数据源

Spring 配置DataSource 的三种方式

(1)使用Spring自带的DriverManagerDataSourceDriverManagerDataSource建立连接

只要有连接就新建一个connection,没有使用连接池。 这里的引用属性是从配置文件jdbc.properties 中读取的。

说明:由于其没有使用连接池,故少在项目中用到。

(2)使用数据源

在Spring中,数据连接是通过数据源获得的。这是一种推荐使用的数据源配置方式,它使用了连接池技术。

Spring在第三方依赖包中包含了两个数据源的实现类包,其一是Apache的DBCP,其二是 C3P0,可以在Spring配置文件中利用这两者中任何一个配置数据源。

DBCP数据源:

org.apache.commons.dbcp.BasicDataSource 
DBCP是一个依赖 Jakarta commons-pool对象池机制的数据库连接池,要在Spring中使用DBCP连接池,需要引入spring-framework-2.0-ml\lob\jakarta-commons文件夹中的commons-collections.jar、commons-dbcp.jar和commons-pool.jar。

下面是DBCP配置片段:

说明:BasicDataSource提供了close()方法关闭数据源,所以必须设定destroy-method=”close”属性, 以便Spring容器关闭时,数据源能够正常关闭。

除以上必须的数据源属性外,还有一些常用的属性:

  • defaultAutoCommit:设置从数据源中返回的连接是否采用自动提交机制,默认值为 true;
  • defaultReadOnly:设置数据源是否仅能执行只读操作, 默认值为 false;
  • maxActive:最大连接数据库连接数,设置为0时,表示没有限制;
  • maxIdle:最大等待连接中的数量,设置为0时,表示没有限制;
  • maxWait:最大等待秒数,单位为毫秒, 超过时间会报出错误信息;
  • validationQuery:用于验证连接是否成功的查询SQL语句,SQL语句必须至少要返回一行数据, 如你可以简单地设置为:“select count(*) from user”;
  • removeAbandoned:是否自我中断,默认是 false ;
  • removeAbandonedTimeout:几秒后数据连接会自动断开,在removeAbandoned为true,提供该值;
  • logAbandoned:是否记录中断事件, 默认为 false;

C3P0数据源:

com.mchange.v2.c3p0.ComboPooledDataSource
C3P0是一个开放源代码的JDBC数据源实现项目,它在lib目录中与Hibernate一起发布,实现了JDBC3和JDBC2扩展规范说明的 Connection 和Statement 池。C3P0类包位于/lib/c3p0/c3p0-0.9.0.4.jar。下面是C3P0配置片段:

说明:ComboPooledDataSource和BasicDataSource一样提供了一个用于关闭数据源的close()方法,这样我们就可以保证Spring容器关闭时数据源能够成功释放。
C3P0拥有比DBCP更丰富的配置属性,通过这些属性,可以对数据源进行各种有效的控制:

  • acquireIncrement:当连接池中的连接用完时,C3P0一次性创建新连接的数目;
  • acquireRetryAttempts:定义在从数据库获取新连接失败后重复尝试获取的次数,默认为30;
  • acquireRetryDelay:两次连接中间隔时间,单位毫秒,默认为1000;
  • autoCommitOnClose:连接关闭时默认将所有未提交的操作回滚。默认为false;
  • automaticTestTable: C3P0将建一张名为Test的空表,并使用其自带的查询语句进行测试。如果定义了这个参数,那么属性preferredTestQuery将被忽略。你不能在这张Test表上进行任何操作,它将中为C3P0测试所用,默认为null;
  • breakAfterAcquireFailure:获取连接失败将会引起所有等待获取连接的线程抛出异常。但是数据源仍有效保留,并在下次调 用getConnection()的时候继续尝试获取连接。如果设为true,那么在尝试获取连接失败后该数据源将申明已断开并永久关闭。默认为 false;
  • checkoutTimeout:当连接池用完时客户端调用getConnection()后等待获取新连接的时间,超时后将抛出SQLException,如设为0则无限期等待。单位毫秒,默认为0;
  • connectionTesterClassName: 通过实现ConnectionTester或QueryConnectionTester的类来测试连接,类名需设置为全限定名。默认为 com.mchange.v2.C3P0.impl.DefaultConnectionTester;
  • idleConnectionTestPeriod:隔多少秒检查所有连接池中的空闲连接,默认为0表示不检查;
  • initialPoolSize:初始化时创建的连接数,应在minPoolSize与maxPoolSize之间取值。默认为3;
  • maxIdleTime:最大空闲时间,超过空闲时间的连接将被丢弃。为0或负数则永不丢弃。默认为0;
  • maxPoolSize:连接池中保留的最大连接数。默认为15;
  • maxStatements:JDBC的标准参数,用以控制数据源内加载的PreparedStatement数量。但由于预缓存的Statement属 于单个Connection而不是整个连接池。所以设置这个参数需要考虑到多方面的因素,如果maxStatements与 maxStatementsPerConnection均为0,则缓存被关闭。默认为0;
  • maxStatementsPerConnection:连接池内单个连接所拥有的最大缓存Statement数。默认为0;
  • numHelperThreads:C3P0是异步操作的,缓慢的JDBC操作通过帮助进程完成。扩展这些操作可以有效的提升性能,通过多线程实现多个操作同时被执行。默认为3;
  • preferredTestQuery:定义所有连接测试都执行的测试语句。在使用连接测试的情况下这个参数能显著提高测试速度。测试的表必须在初始数据源的时候就存在。默认为null;
  • propertyCycle: 用户修改系统配置参数执行前最多等待的秒数。默认为300;
  • testConnectionOnCheckout:因性能消耗大请只在需要的时候使用它。如果设为true那么在每个connection提交的时候都 将校验其有效性。建议使用idleConnectionTestPeriod或automaticTestTable等方法来提升连接测试的性能。默认为false;
  • testConnectionOnCheckin:如果设为true那么在取得连接的同时将校验连接的有效性。默认为false。

其他数据源

  • oracle.jdbc.pool.OracleDataSource:使用Oracle自带的数据源oracle.jdbc.pool.OracleDataSource,Spring使用完这个数据源提供的数据连接后并不进行关闭操作,需要显式的关闭连接。
  • org.logicalcobwebs.proxool.ProxoolDataSource: Proxool是一种Java数据库连接池技术。sourceforge下的一个开源项目,这个项目提供一个健壮、易用的连接池,最为关键的是这个连接池提供监控的功能,方便易用,便于发现连接泄漏的情况。目前是和DBCP以及C3P0一起,最为常见的三种JDBC连接池技术。
  • com.jolbox.bonecp.BoneCPDataSource :bonecp数据连接池, BoneCP最大的特点就是效率,BoneCP号称是目前市面上最快的Java连接池,从官方的评测来看其效率远远超越了其它同类的Java连 接池产品

(3)使用Tomcat提供的JNDI

说明:JndiObjectFactoryBean 能够通过JNDI获取DataSource1

这种方式需要在web server中配置数据源,不方便于部署。

总结

3种方式中,第一种没有使用连接池,故少在项目中用到;第三种方式需要在web server中配置数据源,不方便于部署;通常推荐使用第二种方式进行数据源的配置。

总结

  • 异常处理:Spring对不同ORM异常转换为统一的异常体系;
  • 数据模板:Spring对不同ORM框架定制的统一数据访问模板;
  • DAO配置:Spring对不同ORM提供支持类,用于设置数据访问模板和数据源
  • 事务:Spring对不同ORM框架提供统一的事务管理抽象。事务多线程安全:ThreadLocal;注解配置事务:AOP实现
  • 数据源:连接池

 

参考来源:
《Spring 3.x企业应用开发》第3篇 数据访问 
http://tech.lede.com/2017/02/06/rd/server/SpringTransactional/
<think>好的,我现在需要回答用户关于Spring DAO实现和最佳实践的问题。首先,我得回想一下Spring DAO的核心概念。记得Spring DAO主要是为了简化数据访问的开发,提供了统一的异常处理和数据访问模板。比如,JdbcTemplate就是常用的工具之一,能减少很多样板代码。 接下来要分步骤解释。首先应该介绍Spring DAO的模块,比如属于Spring Framework的哪个部分,支持哪些技术,比如JDBC、Hibernate、JPA等。然后需要提到异常处理,Spring将特定于持久化技术的异常转换成统一的DataAccessException,这样业务就不需要处理各种不同的异常了。 然后是数据访问模板,比如JdbcTemplate的使用方法,举一个例子,比如查询数据或者插入数据。这部分要确保代码示例正确,符合用户的格式要求,使用代码块包裹,并且语法正确。 接下来是事务管理,说明如何通过@Transactional注解来声明事务,以及配置事务管理器的重要性。可能需要提到如何在Spring Boot中自动配置事务管理器,比如使用PlatformTransactionManager的不同实现。 最佳实践部分要包括几个方面:使用JdbcTemplate简化操作,避免原生JDBC的繁琐;异常处理的最佳方式,比如捕获DataAccessException;事务管理的建议,比如在服务使用事务;还有分架构的重要性,保持DAO独立。 然后生成相关问题,需要结合用户之前提供的引用内容。比如用户提到了水平分库的配置,引用[2]里提到根据业务ID分库,避免跨库关联。所以相关问题可以涉及分库分表时如何结合Spring DAO,或者如何优化Spring DAO的性能,事务在分库场景下的处理等。 另外,用户提供的引用[1]提到SpringSource认证的代码和配置,可能需要在最佳实践中提到遵循官方推荐配置,确保代码的可维护性和性能。 需要检查是否符合用户的所有格式要求,比如行内数学表达式用$...$,独立公式用$$...$$,但这个问题可能不涉及数学公式,所以可能不需要。但如果有提到版本号或类似的地方,可能需要用正确的格式。 确保回答结构清晰,分点说明,每个部分有明确的标题,比如核心概念、实现方式、最佳实践。代码示例要正确,使用正确的语法,比如Java代码而不是之前的Python示例。同时,在引用用户提供的引用时,要在适当的位置添加引用标识,比如在提到分库分表时引用[^2]。 最后,生成的相关问题需要与Spring DAO相关,同时结合用户提供的引用内容,比如分库分表的实现、事务管理优化、异常处理等。确保问题有针对性,能够引导用户进一步学习。</think>### Spring DAO实现与最佳实践 #### 1. Spring DAO核心概念 Spring DAO(Data Access Object)是Spring框架中用于简化数据访问(DAL)开发的模块,核心目标是**解耦业务逻辑与数据访问逻辑**,并提供统一的异常处理机制。例如: - **统一异常体系**:将JDBC、Hibernate等技术的特定异常(如`SQLException`)转换为`DataAccessException`,开发者无需处理底差异[^1]。 - **模板模式**:通过`JdbcTemplate`、`HibernateTemplate`等工具类封装重复操作(如连接管理、异常处理)。 #### 2. 实现方式 ##### 2.1 使用JdbcTemplate ```java @Repository public class UserDao { @Autowired private JdbcTemplate jdbcTemplate; public User getUserById(Long id) { return jdbcTemplate.queryForObject( "SELECT * FROM users WHERE id = ?", new Object[]{id}, (rs, rowNum) -> new User(rs.getString("name"), rs.getInt("age")) ); } } ``` 此代码通过`JdbcTemplate`简化了JDBC查询,自动处理资源释放与异常转换。 ##### 2.2 事务管理 通过声明式事务(`@Transactional`)确保操作原子性: ```java @Service public class UserService { @Autowired private UserDao userDao; @Transactional public void updateUser(User user) { userDao.update(user); } } ``` 需配置事务管理器(如`DataSourceTransactionManager`)[^1]。 #### 3. 最佳实践 1. **优先使用JdbcTemplate**:避免原生JDBC的冗余代码,减少资源泄漏风险。 2. **异常处理策略**:捕获`DataAccessException`并记录日志,而非直接暴露底异常。 3. **事务边界控制**:事务注解应作用于服务方法,而非DAO。 4. **分库分表兼容性**:在水平分库场景中,通过业务ID路由数据源,保持DAO无感知。 5. **依赖注入**:通过`@Repository`标注DAO类,利用Spring的组件扫描与依赖注入。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值