从 JDBC 到 MyBatis

JDBC实现查询分析

我们先看看我们最熟悉也是最基础的通过 JDBC 查询数据库数据，一般需要以下七个步骤：

①　加载JDBC驱动；

②　通过驱动管理类获取数据库连接；

③　创建 JDBC Statements 对象；

④　设置SQL语句的传入参数值；

⑤　执行SQL语句，获得查询结果集；

⑥　对查询结果进行转换处理并将处理结果返回；

⑦　释放相关资源（关闭Connection，关闭Statement，关闭ResultSet）；

⑧　对以上所有步骤的异常进行处理；

MyBatis的实现步骤：

第一步优化：连接获取和释放

数据库连接的获取和关闭我们可以使用数据库连接池来解决资源浪费的问题。通过连接池就可以反复利用已经建立的连接去访问数据库了。减少连接的开启和关闭的时间。

可以通过 DataSource 进行隔离解耦，我们统一从 DataSource 里面获取数据库连接，DataSource具体由DBCP实现还是由容器的JNDI实现都可以，所以我们将DataSource的具体实现通过让用户配置来应对变化。

 

 

 

第二步优化：SQL统一存取

我们使用JDBC进行操作数据库时，SQL语句基本都散落在各个JAVA类中，这样有三个不足之处：

可读性很差，不利于维护以及做性能调优

改动Java代码需要重新编译、打包部署

不利于取出SQL在数据库客户端执行（取出后还得删掉中间的Java代码，编写好的SQL语句写好后还得通过＋号在Java进行拼凑）

可以将这些SQL语句统一集中放到配置文件或者数据库里面（以key-value的格式存放）。然后通过SQL语句的key值去获取对应的SQL语句。既然我们将SQL语句都统一放在配置文件或者数据库中，那么这里就涉及一个SQL语句的加载问题。

 

第三步优化：传入参数映射和动态SQL

key-value的Map，解析的时候根据变量名的具体值来判断

JSTL中的<if test=””></if>标签 ——>SQL解析器

 

第四步优化：结果映射和结果缓存

需要返回什么类型的对象。

需要返回的对象的数据结构怎么跟执行的结果映射，这样才能将具体的值赋值到对应的数据结构上

进而考虑对SQL执行结果的缓存来提升性能

 

第五步优化：解决重复SQL语句问题

SQL抽象

SQL引用

 

对比一下我们为什么需要使用MyBatis（优点）

(1) 系统的部分或全部数据来自现有数据库，出于安全性的考虑，只为开发团队提供几条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。　　

(2) 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现（对于金融行业而言，工商银行、中国银行和交通银行，都在开发规范中严格指定）。　　

(3) 系统数据处理量巨大，性能要求极为苛刻，这通常意味着我们必须由经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。

 

 

MyBatis和 hibernate本质上的区：

我们需要认识到的内容：

 

Hibernate: 是一个标准的 ORM 框架（对象关系映射）。学生成本较高，不需要编写sql语句，SQL语句自动生成。对于sql语句的优化，修改比较困难。 
应用场景： 
适合用于sql语句简单的，效率要求不是特别高的项目。

Mybatis: 专注于sql语句，对象映射和输入输出，都由框架帮你完成，所以属于半 ORM系统， 
适用场景： 
sql语句逻辑复杂，效率要求特别高的应用。

以上结论我们对MyBatis是“简单的框架”。