近几年持久化技术领域异常喧嚣，各种框架雨后春笋般地冒出，Sun也连接不断地颁布几个持久化规范。Spring对多个持久化技术提供了集成的支持，包括Hibernate、iBatis、JDO、JPA、TopLink，此外，还通过Sprin g JDBC框架对JDBC API进行简化。Spring面向DAO制定了一个通用的异常体系，屏蔽具体持久化技术的异常，使业务层和具体的持久化技术达到解耦。此外，Spring提供了模板类简化各种持久化技术的使用。通用的异常体系及模板类是Spring整合各种五花八门持久化技术的不二法门，Spring不但借此实现了对多种持久化技术的整合，还可以不费吹灰之力整合潜在的各种持久化框架，体现了“开-闭原则”的经典应用。

　　Spring的DAO理念

　　DAO(Data Access Object)是用于访问数据的对象，虽然我们在大多数情况下，将数据保存在数据库中，但这并不是唯一的选择，你也可以将数据存储到文件中或LDAP中。DAO不但屏蔽了数据存储的最终介质的不同，也屏蔽了具体的实现技术的不同。

　　早期，JDBC是访问数据库的主流选择，近几年，数据持久技术获得了长足的发展，Hibernate、iBatis、JPA、JDO成为持久层中争放异彩的实现技术。只要为数据访问定义好DAO接口，并使用具体的技术实现DAO接口的功能，你就可以在不同的实现技术间平滑的切换。

图 1 业务层通过DAO接口访问数据

　　　　图 1是一个典型的DAO应用实例，在UserDao中定义访问User数据对象的接口方法，业务层通过UserDao操作数据，并使用具体持久技术实现UserDao接口方法，这样业务层和具体持久化技术就实现了解耦。

　　提供DAO层的抽象可以带来一些好处，首先，我们可以很容易地构造模拟对象，方便单元测试的开展，其次在使用切面时，我们有更多的选择：既可以使用JDK动态代理也可以使用CGLib动态代理。

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

　　统一的异常体系

　　统一的异常体系是整合不同的持久化实现技术的关键，Spring提供了一套和实现技术无关的、面向于DAO层次语义的异常体系，并通过转换器将不同的持久化技术异常转换成Spring的异常。

　　Spring的DAO异常体系

　　在很多正统API或框架中，检查型异常被过多的使用，以至在使用API时，代码里充斥着大量的try/catch样板式的代码。在很多情况下，除了在try/catch中记录异常信息以外，我们并没有做多少实质性的工作。引发异常的问题往往是不可恢复的，如数据连接失败，SQL语句存在语法错误，强制捕捉的检查型异常除了限制开发人员的自由度以外，并没有提供什么有意义的作用。因此，Spring的异常体系都是建立在运行期异常的基础上，开发者可以根据需要捕捉感兴趣的异常。

　　JDK很多API之所以难用，一个很大的原因就是检查型异常的泛滥，如JavaMail、EJB以及JDBC等等，使用这些API，一堆堆异常处理的代码喧宾夺主式地侵入业务代码中，破坏了代码的整洁和优雅。

　　Spring在org.springframework.dao包中提供了一套完备优雅的DAO异常体系，这些异常都继承于DataAccessException，而DataAccessException本身又继承于NestedRuntimeException，NestedRuntimeException异常以嵌套的方式封装了源异常。因为虽然不同持久化技术的特定异常被转换到Spring的DAO异常体系中，原始的异常信息并不会丢失，只要你愿意，就可以方便地通过getCause()方法获取原始的异常信息。

　　Spring的DAO异常体系并不和具体的实现技术相关，它从DAO概念的抽象层面定义了异常的目录树。在所有的持久化框架中，我们并没有发现拥有如此丰富语义异常体系的框架，Spring这种设计无疑是独具匠心的，它使得开发人员关注某一特定语义的异常变得容易。在JDBC中的SQLException中，你必须通过异常的getErrorCode()或getSQLState()获取错误代码，直接根据这些代码判断是错误的类型，这种过于底层的API不但带来了代码编写上的难度，而且也使代码的移植变得困难，因为getErrorCode()是数据库相关的。

　　Spring以分类手法建立了异常分类目录，对于大部分应用来说，这个异常分类目录对异常类型的划分具有适当的颗粒度。一方面，使开发者从底层细如针麻的技术细节中脱身出来，另一方面，可以从这个语义丰富的异常体系中选择感兴趣的异常加以处理。图 2列出了那些位于Spring DAO异常体系第一层次的异常类，每个异常类下还可能拥有众多的子异常类：

图 2 Spring DAO异常体系

　　　　Spring DAO异常体系类非常丰富，这里，我们仅列出DataAccessException异常类下的子类。我们可以很容易地通过异常类的名字了解到异常所代表的语义。我们通过下表对这些异常进行简单的描述：

　　表 1 Spring DAO异常体系类

　　

异常	说明
CleanupFailureDataAccessException	DAO操作成功执行，但在释放数据资源时发生异常，如关闭Connection时发生异常等。
ConcurrencyFailureException	表示在进行并发数据操作时发生异常，如乐观锁无法获取、悲观锁无法获取、死锁引发的失败等待异常。
DataAccessResourceFailureException	访问数据资源时失败，如无法获取数据连接，无法获取Hibernate的会话等
DataRetrievalFailureException	获取数据失败，如找不到对应主键的数据，使用了错误的列索引等。
DataSourceLookupFailureException	无法从JNDI中查找到数据源。这个异常是Spring 2.0新增的。
DataIntegrityViolationException	当数据操作违反了数据一致性限制时抛出的异常，如插入重复的主键，引用不存在的外键等。
InvalidDataAccessApiUsageExceptio	不正确地调用某一持久化技术时抛出的异常，如在Spring JDBC中查询对象在调用前必须进行编译操作，如果忘记这项操作将会产生该异常。这种异常不是由底层数据资源产生，而是由不正确地使用持久化技术产生的。
InvalidDataAccessResourceUsage Exception	在访问数据源时使用了不正确的方法所抛出的异常，如SQL语句错误将抛出该异常。
PermissionDeniedDataAccessException	数据访问时由于权限不足引发的异常。如用仅拥有只读权限用户试图进行数据更改操作将抛出该异常。该异常是Spring 2.0新增的。
UncategorizedDataAccessException	其它未分类的异常都归到该异常中。

　　

　　为了进一步细化错误的问题域，Spring对一级异常类进行子类的细分，如InvalidDataAccessResourceUsageException就拥有10多个子类，下面是其中3个子类：

图 3 一级异常类的细化

　　　　对于InvalidDataAccessResourceUsageException异常，不同的持久化实现技术均有对应的子异常类。如 BadSqlGrammarException对应JDBC实现技术SQL语句语法错误的异常，而HibernateQueryExcpetion和TopLinkQueryException分别对应Hibernate和TopLink实现技术的查询语法异常。

　　Spring的这个异常体系具有高度的可扩展性，当Spring需要对一个新的持久化技术提供支持时，只要定义为其定义一个对应的子异常就可以了，这种更改完全满足设计模式中的开-闭原则。

　　虽然Spring定义了如此丰富的异常类，作为开发人员，我们仅需要对感兴趣的异常进行处理就可以了。假设某一个项目要求在发生乐观锁异常时，尝试再次获取乐观锁非不是直接返回错误。那么，我们只需要在代码中显式捕捉ConcurrencyFailureException异常，然后在catch代码块中编写满足需求的逻辑即可。其它众多的异常则可以简单地交由框架自动处理（如发生运行期异常时自动回滚事务）。

关键字:spring dao 设计 思想 nbsp 近几年 | 来源:互联网 | 责任编辑:系统管理员 | 最后编辑:2011年09月28日 03时32分27秒