spring-jdbc 的实现原理

前言

本篇文章将回答以下几个问题

  1. spring-jdbc 的出现是为了解决什么问题
  2. spring-jdbc 如何解决的这些问题
  3. 它的这种技术有何缺陷

首先希望你能带着这些问题来看这篇文章,也希望这篇文章能让你很好的解答这些问题。当然,这篇文章的终极目标是希望你能够借鉴spring-jdbc 的思想来解决我们在工作过程中所面临的问题。

如果你想了解,如何使用spring-jdbc,请绕道……

Dao 模式

为了实现数据和业务的分离,有人提出了Dao模式。Dao模式是数据处理的一种理想模式,(我认为)它带来了两个方面的好处:1、屏蔽数据访问的差异性;2、业务与数据分离。spring-jdbc 在本质上是一种Dao模式的具体实现。(Dao模式的详细介绍)

接下下我们用一个简单的例子(未具体实现)来简单介绍一下Dao模式(如下图所示)

spring-jdbc 的实现原理

从上面的UML图可以知道:

  • 首先定义了一个User的操作接口UserDao,它定义了了获取用户信息、添加用户信息、更改用户信息的行为;
  • 具体行为的由其实现类来实现,我们这里举了两个例子:Batis 实现和Jdbc实现(当然也可以缓存实现或file实现等),它实现具体获取或修改数据的行为;UserDaoFactory 生成具体的实现UserDao实现类(请参考下面代码)。
  • 所以当我们在Service层(UserService)访问数据时,只 需要使用UserDaoFactory 生成一个具体的UserDao实现类就可以了,这样业务层就可以完全操作数据操作的具体实现( 参考下面UserService的具体实现)
public class User {
    private int id;
    private String name;
    private String email;
    private String phone;

    public User() {
    }

    public int getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public String getEmail() {
        return email;
    }

    public String getPhone() {
        return phone;
    }

    public void setId(int id) {
        this.id = id;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public void setPhone(String phone) {
        this.phone = phone;
    }
}
public interface UserDaoInterface {
    public User getUserInfoByName(String name);
    public void putUserInfo(User user);
    public void updateUserInfo(User user);
}
public class UserDaoJdbcAccessImpl implements UserDaoInterface {
    // Jdbc连接数据库等操作,未完成具体实现
    private DataSource dataSource;
    public User getUserInfoByName(String name) {
        dataSource.getC

        return new User();
    }
    public void putUserInfo(User user) {

    }
    public void updateUserInfo(User user) {

    }
}
public class UserDaoBatisAccessImpl implements UserDaoInterface {
    // Batis连接数据库等操作,未完成具体实现
    public User getUserInfoByName(String name) {
        return new User();
    }
    public void putUserInfo(User user) {

    }
    public void updateUserInfo(User user) {

    }
}
public class UserDaoFacotry {

    public static UserDaoInterface getUserDao(int which) {
        switch(which) {
            case 1:
                return new UserDaoJdbcAccessImpl();
            case 2:
                return new UserDaoBatisAccessImpl();
            default:
                return null;
        }
    }
}
public class UserService {

    public UserDaoInterface getUserDaoOperation() {
        return UserDaoFacotry.getUserDao(1);
    }

    public void getUserInfo() {

        User user = this.getUserDaoOperation().getUserInfoByName("xiaoming");
    }
}

但在具体实现DaoImpl时遇到了一个问题,数据库的连接访问会抛出异常,且属于checked exception

public User getUserInfoByName(String name) {
    try {
        Connection connection = dataSource.getConnection();
        User user = ....
        return user;
    } catch (SQLException e) {

    } finally {
        connection.close();
    }
}

这是很尴尬的,因为此时我们不知道是要抛给上层业务还是catch之后进行处理。catch之后进行处理,由于屏蔽异常会让客户端难以排查问题,如果直接抛出去也带来更严重的问题(必须更改接口且不同数据库所抛出的异常不一样),如下所示

public User getUserInfoByName(String name) throw SQLException, NamingException ... {
    try {
        Connection connection = dataSource.getConnection();
        User user = ....
        return user;
    } finally {
        connection.close();
    }
}

jdbc 为了解决不同数据库带来的异常差异化,则对异常进行统一转换,并抛出unchecked异常。具体抛出的异常可以在org.springframework.dao中查看

spring-jdbc 的实现原理

这是很尴尬的,因为此时我们不知道是要抛给上层业务还是catch之后进行处理。catch之后进行处理,由于屏蔽异常会让客户端难以排查问题,如果直接抛出去也带来更严重的问题(必须更改接口且不同数据库所抛出的异常不一样),如下所示

具体异常所代表的含义:

Spring的DAO异常层次

异常 何时抛出
CleanupFailureDataAccessException 一项操作成功地执行,但在释放数据库资源时发生异常(例如,关闭一个Connection
DataAccessResourceFailureException 数据访问资源彻底失败,例如不能连接数据库
iMac 10000 元
DataIntegrityViolationException Insert或Update数据时违反了完整性,例如违反了惟一性限制
DataRetrievalFailureException 某些数据不能被检测到,例如不能通过关键字找到一条记录
DeadlockLoserDataAccessException 当前的操作因为死而失败
IncorrectUpdateSemanticsDataAccessException Update时发生某些没有预料到的情况,例如更改超过预期的记录数。当这个异常被抛出时,执行着的事务不会被回滚
InvalidDataAccessApiusageException 一个数据访问的JAVA API没有正确使用,例如必须在执行前编译好的查询编译失败了
invalidDataAccessResourceUsageException 错误使用数据访问资源,例如用错误的SQL语法访问关系型数据库
OptimisticLockingFailureException 乐观锁的失败。这将由ORM工具或用户的DAO实现抛出
TypemismatchDataAccessException Java类型和数据类型不匹配,例如试图把String类型插入到数据库的数值型字段中
UncategorizedDataAccessException 有错误发生,但无法归类到某一更为具体的异常中

spring-jdbc

我们可以将spring-jdbc 看作Dao 模式的一个最佳实践,它只是使用了template模式,实现了最大化的封装,以减少用户使用的复杂性。spring-jdbc 提供了两种模式的封装,一种是Template,一种是操作对象的模式。操作对象的模式只是提供了面向对象的视觉(template 更像面向过程),其底层的实现仍然是采用Template。

接下来我们将会了解Template 的封装过程。

2.1 Template

还是延用上述例子,如果这里我们需要根据用户名查询用户的完整信息,将采用下面的方式实现查询

public class UserDaoJdbcAccessImpl implements UserDaoInterface {
    // Jdbc连接数据库等操作,未完成具体实现
    private DataSource dataSource;
    public User getUserInfoByName(String name) {
        String sql = "....." + name;
        Connection connection = null;
        try {
            connection = DataSourceUtils.getConnection(dataSource);
            Statement statement = connection.createStatement();
            ResultSet resultSet = statement.executeQuery(sql);
            List<User> userList = Lists.newArrayList();
            while(resultSet.next()) {
                User user = new User();
                user.setId(resultSet.getInt(1));
                user.setName(name);
                user.setEmail(resultSet.getString(3));
                user.setPhone(resultSet.getString(4));
                userList.add(user);
            }
            connection.close();
            connection = null;
            statement.close();
            return userList;
        } catch (Exception e) {
            throw new DaoException(e);
        } finally {
            if (connection != null) {
                try {
                    connection.close();
                } catch (SQLException e) {
                    log.error(".....");
                }
            }
        }
    }

当我们只需要完成一个操作的项目时,这种方式还可以接受,但当项目中有大量的DAO需要操作时,难免过程中会出现各种问题,如忘记关闭连接等。

其实我们可以发现整个的数据库的操作实现可以分为四个部分:资源管理(数据库的连接关闭等操作)、sql执行(查询、更新等)、结果集的处理(将sql查询结果转化)、异常处理。

那是不是可以将公共部分抽象成一个模板进行使用呢?现在我们来定义一个Jdbc的一个模板

public class JdbcTemplate {
    public final Object execute(StatementCallback callback) {
        Connection connection = null;
        Statement statement = null;
        try {
            connection = getConnetion();
            statement = con.createStatement();
            Object ret = callback.doWithStatement(callback);
            return retValue;
        } catch (SQLException e) {
            DateAccessException ex = translateSqlException(e);
            throw ex;
        } finally {
            closeStatement(statement);
            releaseConnection(connection);
        }
    }
}

Template 定义了关注了操作的所有过程,只需要传递一个callback,就可以帮我们处理各种细节化操作,这些细节化操作包括:获取数据库连接;执行操作;处理异常;资源释放。那我们在使用时就可以简化为

private JdbcTemplate jdbcTemplate;
// Jdbc连接数据库等操作,未完成具体实现
private DataSource dataSource;
public User getUserInfoByName(String name) {
    StatementCallback statementCallback = new StatementCallback() {
        @Override
        public Object doInStatement(Statement stmt) throws SQLException, DataAccessException {
            return null;
        }
    }
     return jdbcTemplate.execute(statementCallback);

}

实际上,Template 在封装时远比这个复杂,接下来我们就看一下spring-jdbc 是如何对jdbc进行封装的

spring-jdbc 的实现原理

JdbcTemplate 实现了JdbcOperations接口和继承了JdbcAccessor。

JdbcOperations 定义了数据库的操作,excute、 query、update 等,它是对行为的一种封装。

JdbcAccessor 封装了对资源的操作以及异常的处理,可以看一下源码,比较短。

public abstract class JdbcAccessor implements InitializingBean {

   /** Logger available to subclasses */
   protected final Log logger = LogFactory.getLog(getClass());

   private DataSource dataSource;

   private SQLExceptionTranslator exceptionTranslator;

   private boolean lazyInit = true;


   /**
    * Set the JDBC DataSource to obtain connections from.
    */
   public void setDataSource(DataSource dataSource) {
      this.dataSource = dataSource;
   }

   /**
    * Return the DataSource used by this template.
    */
   public DataSource getDataSource() {
      return this.dataSource;
   }

   /**
    * Specify the database product name for the DataSource that this accessor uses.
    * This allows to initialize a SQLErrorCodeSQLExceptionTranslator without
    * obtaining a Connection from the DataSource to get the metadata.
    * @param dbName the database product name that identifies the error codes entry
    * @see SQLErrorCodeSQLExceptionTranslator#setDatabaseProductName
    * @see java.sql.DatabaseMetaData#getDatabaseProductName()
    */
   public void setDatabaseProductName(String dbName) {
      this.exceptionTranslator = new SQLErrorCodeSQLExceptionTranslator(dbName);
   }

   /**
    * Set the exception translator for this instance.
    * <p>If no custom translator is provided, a default
    * {@link SQLErrorCodeSQLExceptionTranslator} is used
    * which examines the SQLException's vendor-specific error code.
    * @see org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator
    * @see org.springframework.jdbc.support.SQLStateSQLExceptionTranslator
    */
   public void setExceptionTranslator(SQLExceptionTranslator exceptionTranslator) {
      this.exceptionTranslator = exceptionTranslator;
   }

   /**
    * Return the exception translator for this instance.
    * <p>Creates a default {@link SQLErrorCodeSQLExceptionTranslator}
    * for the specified DataSource if none set, or a
    * {@link SQLStateSQLExceptionTranslator} in case of no DataSource.
    * @see #getDataSource()
    */
   public synchronized SQLExceptionTranslator getExceptionTranslator() {
      if (this.exceptionTranslator == null) {
         DataSource dataSource = getDataSource();
         if (dataSource != null) {
            this.exceptionTranslator = new SQLErrorCodeSQLExceptionTranslator(dataSource);
         }
         else {
            this.exceptionTranslator = new SQLStateSQLExceptionTranslator();
         }
      }
      return this.exceptionTranslator;
   }

   /**
    * Set whether to lazily initialize the SQLExceptionTranslator for this accessor,
    * on first encounter of a SQLException. Default is "true"; can be switched to
    * "false" for initialization on startup.
    * <p>Early initialization just applies if {@code afterPropertiesSet()} is called.
    * @see #getExceptionTranslator()
    * @see #afterPropertiesSet()
    */
   public void setLazyInit(boolean lazyInit) {
      this.lazyInit = lazyInit;
   }

   /**
    * Return whether to lazily initialize the SQLExceptionTranslator for this accessor.
    * @see #getExceptionTranslator()
    */
   public boolean isLazyInit() {
      return this.lazyInit;
   }

   /**
    * Eagerly initialize the exception translator, if demanded,
    * creating a default one for the specified DataSource if none set.
    */
   @Override
   public void afterPropertiesSet() {
      if (getDataSource() == null) {
         throw new IllegalArgumentException("Property 'dataSource' is required");
      }
      if (!isLazyInit()) {
         getExceptionTranslator();
      }
   }

}

源码有三个参数:datasource、exceptionTranslator(转换各种数据库方案商的不同的数据库异常)、lazyInit(延时加载:是否在applicationContext 初始化时就进行实例化)

在使用的过程中我们可以看到,只需要提供一个statementCallback,就可以实现对Dao 的各种操作。spring-jdbc 为了满足各种场景的需要,为我们提供了四组不同权限的callback

在使用的过程中我们可以看到,只需要提供一个statementCallback,就可以实现对Dao 的各种操作。spring-jdbc 为了满足各种场景的需要,为我们提供了四组不同权限的callback

callback 说明
CallableStatementCallback 面向存储过程
ConnectionCallback 面向连接的call,权限最大(但一般情况应该避免使用,造成操作不当)
PreparedStatementCallback 包含查询询参数的的callback,可以防止sql 注入
StatementCallback 缩小了ConnectionCallback的权限范围,不允许操作数据库的连接

我们再看一下JdbcTemplate 的封装

public <T> T execute(ConnectionCallback<T> action) throws DataAccessException {
   Assert.notNull(action, "Callback object must not be null");

   Connection con = DataSourceUtils.getConnection(getDataSource());
   try {
      Connection conToUse = con;
      if (this.nativeJdbcExtractor != null) {
         // Extract native JDBC Connection, castable to OracleConnection or the like.
         conToUse = this.nativeJdbcExtractor.getNativeConnection(con);
      }
      else {
         // Create close-suppressing Connection proxy, also preparing returned Statements.
         conToUse = createConnectionProxy(con);
      }
      return action.doInConnection(conToUse);
   }
   catch (SQLException ex) {
      // Release Connection early, to avoid potential connection pool deadlock
      // in the case when the exception translator hasn't been initialized yet.
      DataSourceUtils.releaseConnection(con, getDataSource());
      con = null;
      throw getExceptionTranslator().translate("ConnectionCallback", getSql(action), ex);
   }
   finally {
      DataSourceUtils.releaseConnection(con, getDataSource());
   }
}

有两个需要注意的地方

Connection con = DataSourceUtils.getConnection(getDataSource());

这里创建连接使用的是DataSourceUtils,而不是datasource.getConnection,这是由于考虑到了事务处理的因素。

if (this.nativeJdbcExtractor != null) {
         // Extract native JDBC Connection, castable to OracleConnection or the like.
         conToUse = this.nativeJdbcExtractor.getNativeConnection(con);
      }

这里并不一定使用的是jdbc的connection,因为jdbc是一种统一化封装,而忽略了各个sql供应商的差异性。有时间我们需要使用某一数据库的某种特性(比如Oracle sql)时,就可以通过对nativeJdbcExtractor来达到目的。

JdbcTemplate 还有几个演生的template,这里都不再详细介绍。

Ok,关于template 的介绍就到此为止(这里更倾向于介绍各种技术的实现原理,而非如何使用)。

2.2 对象模式

对象模式其实只是把Template 中的操作封装成各个对象,而其本质的实现方式仍然是Template

spring-jdbc 的实现原理

三、缺陷

spring-jdbc的封装方式得到了广泛认可,但并不代表它是一个友好的的操作数据库的工具。 从上面的介绍过程中,我们可以感受到jdbc 的封装是面向底层的,所以它对于上层的使用方并不那么友好。jdbc 并未能真正的实现业务和数据的完全分离,对callback的定义仍然会穿插在业务当中,所以在实际的业务应用中,已经很少直接使用jdbc。因此spring 也对很多其它的ORM框架进行了支持,如ibatis,hibernate,JDO等等,这些更高级对用户更加友好。接下我会用一系列文章,对这些框架进行介绍

四、总结

我们再来回顾一下最前面提出的三个问题:

  1. spring-jdbc 是为了解决数据和业务分离的问题,使客户端能够更专注于业务层面,而不必关注数据库资源的连接释放及异常处理等逻辑。
  2. spring-jdbc 采用dao模式实现了业务和数据的分离;使用模板模式,实现了逻辑的封装
  3. spring-jdbc 属于面向低层的实现,对用户不太友好。

个人能力有限,有错误之处还请指证…..

原文 

https://juejin.im/post/5969a1eb6fb9a06ba26886dd

PS:如果您想和业内技术大牛交流的话,请加qq群(527933790)或者关注微信公众 号(AskHarries),谢谢!

转载请注明原文出处:Harries Blog™ » spring-jdbc 的实现原理

赞 (0)

分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址