这篇博客 来自spring揭秘一书的第十三章

为什么要有访问异常都有一个体系,这个我们得从DAO模式说起。

DAO模式

任何一个系统,不管是一个最简单的小系统,还是大规模的系统,都得跟数据打交道,说白了都得时常进行存取数据的操作。我们暂且不论数据本身,数据存储的方式就已经是各有不同了。

最简单的,把数据存储到关系型数据库中。这里面至少就有MySQL,Oracle等等

我还可以把数据存储到文本文件里。

还可以把数据存储到csv文件中(关于csv,大家百度之)

还有LDAP(Lightweight Directory Access Protocol)轻量目录访问协议





为了统一和简化系统访问这不同存储方式的数据,就提出了DAO模式。

换句话说,DAO层干的就是屏蔽因为不同的数据存储方式而带来存取差异。

我再说的简单点,在我们的系统里,一般会有一个总的DAO类,是一个接口。

然后就是有MySQLDaoImpl,OracleDaoImpl等等。






举个例子吧,我们看一个访问顾客的例子

public interface IUserDao{
    public User findUserByPK(Integer id);
    public void updateUser(User user);
}

在服务层的代码里,我们只有声明一个IUserDao型的实例变量,并让spring给我们注入即可

public class UserService{
    private IUserDao userDao;

    public IUserDao getUserDao(){
        return userDao;
    }

    public void setUserDao(IUserDao userDao){
        this.userDao = userDao;
    }

    public void disableUser(Integer userId){
        User user = this.userDao.findUserByPK(userId);
        userDao.updateUser(user);
    }
}

假定我们的数据存储在关系型数据库中

那么我就给IUserDao来一个jdbc的实现

public class JDBCUserDao implements IUserDao{

    @Override
    public User findUserByPK(Integer id){
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public void updateUser(User user){
        // TODO Auto-generated method stub
     }
}

如果以后数据需要从关系型数据库中迁移到文本文件中(我知道这个假设很扯淡,就是为了说明如果后来数据的存储方式发生了改变),那么我们再实现一个TextUserDao即可

public class TextUserDao implements IUserDao{

    @Override
    public User findUserByPK(Integer id){
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public void updateUser(User user){
        // TODO Auto-generated method stub
     }
}

我们需要改动的地方,就是再spring的配置文件里,把UserService的配置变一下即可。



看到了吧,DAO的优势就在于可以屏蔽由不同的数据访问机制的差异而导致的存储差异。

Exception处理的问题

这样就OK了吗,似乎是OK了。

这么吧,我们把JDBCUserDao补充完整。

import java.sql.Connection;

import javax.sql.DataSource;

public class JDBCUserDao implements IUserDao{
    //省略datasource的getset
    private DataSource dataSource ;

    @Override
    public User findUserByPK(Integer id){
        Connection conn = null;
        try{
            conn = getDataSource().getConnection();
            //....
            User user = new User();
            //........
            return user;
        }
        catch (SQLException e){
            //是抛出异常,还是在当前位置处理。。。
        }
        finally{
            releaseConnection(conn);
        }
        return null;
    }

    //省略updateuser与releaseConnection
}

问题就在于try catch里,如果捕获到异常

是抛出呢,还是就直接处理呢?

如果是直接就处理了,那么service就收到一个null,它什么都不知道,那这怎么整?

那就只能抛给service层了。

不过,JDBCUserDao类的findUserByPK方法的签名就得改一改了。

public User findUserByPK(Integer id) throws SQLException

同样的IUserDao的签名也得改一次

public User findUserByPK(Integer id) throws SQLException;





这样一来就带来了两个问题

1 我们引入DAO的目的就是为了统一,不管使用什么样的数据存储机制,客户端(也就是service层)应该是不变的,现在因为使用关系型数据库,需要抛出特定的SQLException,那么你让service层怎么办?加上处理SQLException的逻辑?如果我不用关系型数据库了,我使用文本方式存储数据,那么就肯定不会抛出SQLException。你又让Service层怎么办?

2 如果我使用了文本方式来存储数据,findUserByPK方法需要抛出一个TextExcetpin(这个异常是我杜撰的),那怎么办?再改签名吗?

public User findUserByPK(Integer id) throws SQLException,TextExcetpin;

如果存储机制再改变,我们又继续添加抛出的异常类型,这个设计也太糟糕了吧。





就目前来看,我们的dao似乎建造了一个空中楼阁。

包装Exception

问题来了,不要怕,解决它就是了。

上面的问题的核心是,不同的dao的实现会抛出不同的异常,如果对每一种异常都处理一下,我们的dao层的设计也就没有意义了。

那么我们把不同的异常,包装成一个统一的异常不就OK了?

包装成什么异常呢?checked exception还是unchecked exception呢?





这里我简要介绍一下这两种异常。

Exception的子类有两类

一类是 类似NullPointerException这种,继承自RuntimeException(RuntimeException又继承自Exception),在出现RuntimeException的地方,我们不需要try catch,方法的签名处也不需要声明throws,这类exception我们称之为unchecked exception

另一类是 类似ClassNotFound,SQLExceptin这种,直接继承自Exception。这种异常必须得try catch,如果不及时捕获的话,在方法的签名处就得声明 throws。这类exception我们称之为checked exception。





我们现在的情况是,在dao里面的exception需要抛出,但是抛出后,我们需要service层怎么处理?最好的办法就是不做处理,仅仅让他知道就ok。

那么我们选择unchecked exception

这么一来JDBCUserDao的核心代码就是下面的样子了:

public User findUserByPK(Integer id){
	try{
	 conn = getDataSource().getConnection();
	 //....
	  User user = new User();
	   Statement stmt = conn.createStatement();
	   stmt.execute("");
	   //........
	  return user;
	}
	catch (SQLException e){
	   throw new RuntimeException(e);
	}
}

关键问题是,因为RuntimeException不需要在方法的签名处声明throws

我们的方法签名又回归大一统了。

public User findUserByPK(Integer id)

另外还有一个小问题,就拿关系型数据库来说吧,mysql与oracle的错误包装方式不一样,有的数据库提供商采用SQLException的ErrorCode作为具体的错误信息标准,有的数据库提供商则通过SQLException的SqlState来返回相信的错误信息。如果直接像上面的那样子直接抛出一个RuntimeException,那么客户端要想知道错误信息还不知道去errorcode看还是去sqlstate看呢。

怎么办?我们使用分类转译的方式,改成下面的样子

catch (SQLException e){
    //是抛出异常,还是在当前位置处理。。。
    if(isMysqlVendor()){
        //按照mysql数据库的规则分析错误信息然后抛出
        throw new RuntimeException(e);
    }
    if(isOracleVendor()){
        //按照oracle数据库的规则分析错误信息并抛出
        throw new RuntimeException(e);
    }
    throw new RuntimeException(e);
}

或者我们可以吧上面的两个if判断装到一个工具类里面去。





还有一个问题,上面的处理方式,所有的异常其实就一个RuntimeException。还不够细致。

比如,数据库连接不上、ldap服务器连接失败,他们被认为是资源获取失败;而主键冲突或者是其它的资源冲突,他们被认为是数据访问一致性冲突。针对这些情况,可以为RuntimeException为基准,为获取资源失败这种情况分配一个RuntimeException子类型,称其为ResourceFailerException,而数据一致性冲突对应另外一个子类型DataIntegrityViolationException,其它的分类异常可以加以类推,所以我们需要的只是一套unchecked exception类型的面向数据访问领域的异常层次类型。

不需要重新发明轮子

spring已经为我们做好了下面的异常体系:

DataAccessException位于org.springframework.dao中

上面各种exception的具体职责,我就不细说了,大家百度之。

参照资料

http://my.oschina.net/u/218421/blog/38478

Spring揭秘读书笔记 八 数据访问异常体系的更多相关文章

  1. Spring揭秘 读书笔记 三 bean的scope与FactoryBean

    本书可作为王富强所著<<Spring揭秘>>一书的读书笔记  第四章 BeanFactory的xml之旅 bean的scope scope有时被翻译为"作用域&quo ...

  2. spring揭秘 读书笔记 二 BeanFactory的对象注册与依赖绑定

    本文是王福强所著<<spring揭秘>>一书的读书笔记 我们前面就说过,Spring的IoC容器时一个IoC Service Provider,而且IoC Service Pr ...

  3. spring揭秘 读书笔记 一 IoC初探

    本文是王福强所著<<spring揭秘>>一书的读书笔记 ioc的基本概念 一个例子 我们看下面这个类,getAndPersistNews方法干了四件事 1 通过newsList ...

  4. spring揭秘 读书笔记 二 BeanFactory的对象注冊与依赖绑定

    本文是王福强所著<<spring揭秘>>一书的读书笔记 我们前面就说过,Spring的IoC容器时一个IoC Service Provider,并且IoC Service Pr ...

  5. Spring.Net学习笔记(二)-数据访问器

    Spring对ADO.NET也提供了支持,依赖与程序集Spring.Data.dll IDbProvider IDbProvider定义了数据访问提供器的基础,配置如下 <?xml versio ...

  6. Spring揭秘 读书笔记 七 BeanFactory的启动分析

    首先,先看我自己画的BeanFactory启动时的时序图. 第一次接触时序图,可能有些地方画的不是很符合时序图的规则,大家只关注调用顺序即可. public static void main(Stri ...

  7. spring揭秘 读书笔记 六 bean的一生

    我们知道,Spring容器具有对象的BeanDefinition来保存该对象实例化时需要的数据. 对象通过container.getBean()方法是才会初始化该对象. BeanFactory 我们知 ...

  8. spring揭秘读书笔记----spring的ioc容器之BeanFactory

    spring的ioc容器是一种特殊的Ioc Service Provider(ioc服务提供者),如果把普通的ioc容器认为是工厂模式(其实很相似),那spring的ioc容器只是让这个工厂的功能更强 ...

  9. Spring揭秘 读书笔记 五 容器的启动

    Spring的IoC容器所起的作用,就是生产bean,并维持bean间的依赖关系.它会以某种方式加载Configuration Metadata(通常也就是XML格式的配置信息),然后根据这些信息绑定 ...

随机推荐

  1. python笔记十二(匿名函数)

    一.匿名函数 有些情况下,我们需要把函数当做参数传入到另外的函数中,或者是把函数作为某个函数的返回值,此时我们就可以使用匿名函数. 匿名函数的标志是lambda.   >>> f = ...

  2. beta 分布的详细介绍(转载)

    目前看到的关于beta分布最好的一个解释,由于贴过来格式不好看,所以附上链接: http://www.datalearner.com/blog/1051505532393058

  3. HashMap 和 HashTable 区别

    来源:http://www.importnew.com/7010.html HashMap和Hashtable的区别 HashMap和Hashtable都实现了Map接口,但决定用哪一个之前先要弄清楚 ...

  4. jboss规则引擎KIE Drools 6.3.0 Final 教程(1)

    前言 目前世面上中文的KIE DROOLS Workbench(JBOSS BRMS)的教程几乎没有,有的也只有灵灵碎碎的使用机器来翻译的(翻的不知所云)或者是基于老版本的JBOSS Guvnor即5 ...

  5. 机器学习系列(3)_逻辑回归应用之Kaggle泰坦尼克之灾

    作者:寒小阳 && 龙心尘 时间:2015年11月. 出处: http://blog.csdn.net/han_xiaoyang/article/details/49797143 ht ...

  6. springMVC源码分析--AbstractHandlerMapping(二)

    上一篇博客springMVC源码分析--HandlerMapping(一)中我们简单的介绍了HandlerMapping,接下来我们介绍一下它的抽象实现类AbstractHandlerMapping

  7. MS Office2016留下的坑

    背景 问题源自论坛用户反馈,他用管家有几年了,之前使用IE都很正常,没有任何问题,但是最近突然发现,启动IE时,就会出现系统错误提示:无法启动此程序,因为计算机中丢失 api-ms-win-core- ...

  8. Ubuntu使用dpkg安装软件依赖问题解决 ubuntu-tweak ubuntu 16.04 LTS 系统清理

    Ubuntu使用dpkg安装软件依赖问题解决 这里以在ubuntu 16.04安装Ubuntu Tweak为例进行说明,通常安装包依赖问题都可以用这种方法解决: sudo apt-get instal ...

  9. 【安卓开发】Android系统中Parcelable和Serializable的区别

    http://greenrobot.me/devpost/android-parcelable-serializable/ 进行Android开发的时候,我们都知道不能将对象的引用传给Activiti ...

  10. [django] 利用多线程增加异步任务

    看到django异步大家的反应应该是celery这种消息队列组件,现在用的最多的最推荐的也是这种方式.然而我这需求就是请求来了,执行一个小程序,但是又不能确定这个小程序啥时候执行完,响应又要及时,丢给 ...