诞生的背景

什么背景下诞生了该技术？

不论是哪个框架，不会平白无故诞生，不会平白无故的被人所追捧，了解其背景，追根溯源。

Mybatis也好、Ibatis也罢，本质都是一个ORM框架，那么ORM是什么？ORM在什么背景下诞生的呢？

ORM是什么？

ORM即对象关系映射。

ORM诞生背景

面向对象编程大行其道，应用开始频繁的与存储打交道，需要频繁的访问数据库。但是面向对象编程和数据库存储两者怎么对应，怎么快速访问，快速编程就成了一个问题。

面向对象是从软件工程基本原则（如耦合、聚合、封装）的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。

为了解决这个不匹配的现象，对象关系映射技术应运而生。

Ibatis的诞生背景

iBATIS一词来源于“internet”和“abatis”的组合，是一个由Clinton Begin在2001年发起的开放源代码项目。最初侧重于密码软件的开发，现在是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的JPetStore实例。

它解决了什么痛点、什么问题？

技术没有银弹，只有实事求是，解决问题。

讲解其解决痛点之前，我们先来看下其所工作的位置，一般位于Dao层，通过mybatis与jdbc打交道，然后对数据库进行读写操作。

不知道还有没有人记得没有ORM框架之前我们是如何跟数据库打交道的？

是的，JDBC API。

JDBC API流程大致如下

大家分析一下有什么痛点？

1. 我们需要手动管理连接
2. 我们需要关闭资源
3. 我们需要映射参数
4. 我们需要映射结果集
5. 我们需要硬编码SQL

ORM框架让我们原先使用原生JDBC API与数据库打交道的方式变得更加简洁、易维护。

ORM框架就帮我们解决了这些问题。那么接下来我们来分析下Mybatis的优缺点

它有什么优缺点？

没有完美的技术、完美的框架、完美的实现。

优点

1. 代码不再需要硬编码，我们可以放在XML里统一管理
2. 动态SQL，灵活的组装SQL
3. 结果集自动映射
4. XML里可以编写原生SQL，可以对SQL进行优化

缺点

1. 优点必然伴随缺点，编写针对性的编写原生SQL必然会带来难以迁移的问题。（不过现在很少说从某个数据库迁到某个数据库）
2. 复杂的业务场景必然伴随着复杂的SQL拼接，这种基本是业务的通病，也不能全算是Mybatis自己的缺点。

有什么核心功能特性、亮点

这个技术有哪些核心的功能，亮点是什么？能给我们带来什么价值、收益？

ORM基础能力

面向Mybatis API编程，不再关注JDBC。

结果集映射

自动映射

<select id="selectUsers" resultType="User">
  select
    user_id             as "id",
    user_name           as "userName",
    hashed_password     as "hashedPassword"
  from some_table
  where id = #{id}
</select>

<select id="selectUsers" resultType="map">
  select id, username, hashedPassword
  from some_table
  where id = #{id}
</select>

手动映射ResultMap

<resultMap id="userResultMap" type="User">
  <id property="id" column="user_id" />
  <result property="username" column="user_name"/>
  <result property="password" column="hashed_password"/>
</resultMap>

<select id="selectUsers" resultMap="userResultMap">
  select user_id, user_name, hashed_password
  from some_table
  where id = #{id}
</select> 

动态SQL

XML方式

<select id="findActiveBlogLike"
     resultType="Blog">
  SELECT * FROM BLOG WHERE state = ‘ACTIVE’
  <if test="title != null">
    AND title like #{title}
  </if>
  <if test="author != null and author.name != null">
    AND author_name like #{author.name}
  </if>
</select>

SQL对象构建器

private String selectPersonSql() {
  return new SQL() {{
    SELECT("P.ID, P.USERNAME, P.PASSWORD, P.FULL_NAME");
    SELECT("P.LAST_NAME, P.CREATED_ON, P.UPDATED_ON");
    FROM("PERSON P");
    FROM("ACCOUNT A");
    INNER_JOIN("DEPARTMENT D on D.ID = P.DEPARTMENT_ID");
    INNER_JOIN("COMPANY C on D.COMPANY_ID = C.ID");
    WHERE("P.ID = A.ID");?
    WHERE("P.FIRST_NAME like ?");
    OR();
    WHERE("P.LAST_NAME like ?");
    GROUP_BY("P.ID");
    HAVING("P.LAST_NAME like ?");
    OR();
    HAVING("P.FIRST_NAME like ?");
    ORDER_BY("P.ID");
    ORDER_BY("P.FULL_NAME");
  }}.toString();
}

SQL统一管理

所有的SQL，存放在对应的XXXMapper.xml这样的配置文件中，统一管理。

核心功能实现原理、追其本质

芒格曾经说过，我们要学习重要学科的重要原理，像我们学习技术一样，我们要学习主要框架的核心实现原理，了解其本质，了解其解决的痛点，追其本质。

工作流程

本质是什么？

原来呢，我们是自己通过原生JDBC API跟数据库打交道，现在有了Mybatis，我们通过Mybatis跟数据库打交道，更方便了。但是呢，我们跟数据库打交道的底层没关系，因为我们只能通过相关协议，相关底层标准的API，即JDBC API、xxx数据库协议跟xxx数据库打交道。

这里思考一个问题：通过别人帮助我们打交道的方式，我们叫什么？

有人可能已经猜到了，是的，代理模式，Mybatis里用了大量的代理模式。那么我们来看看Mybatis的工作流程。

为何如此发展

分析发展路线图、分析核心版本，追根溯源。

Ibatis和Mybatis，不仅仅是名字的改变。

Ibatis在2010年前后就已经不再维护了，Ibatis团队投奔Google，Ibatis 3.x改名成了Mybatis。

Mybatis的功能更加强大，我们现在用的注解、插件扩展都是3.0之后才有的。

最后再来说明一下其本质，其本质就是代理，对JDBC的代理。 mybatis最初是对JDBC包了一层，通过代理帮助我们对JDBC API进行管理，再后来就对其易用性做了提升，比如注解方式的使用，插件扩展（PageHelper等插件）。