诞生的背景

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

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

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流程大致如下

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

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

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

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

它有什么优缺点？

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

优点

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

缺点

优点必然伴随缺点，编写针对性的编写原生SQL必然会带来难以迁移的问题。（不过现在很少说从某个数据库迁到某个数据库）
复杂的业务场景必然伴随着复杂的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等插件）。

内容出处：，

声明：本网站所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品，请与我们取得联系，我们会及时修改或删除。文章链接：http://www.yixao.com/tech/23530.html