Mybatis 源码学习-简介

Mybatis 源码的学习相比于Spring 源码的的学习则要相对容易得多了，主要体现在两个方面：

1. 代码体量比Spring 小
2. ORM框架功能简单

那Mybatsi该怎么学习，要哪些要掌握的？

我认为以下在学习完Spring 源码之后需要掌握的

1. 清楚理解传统JDBC和Mybatis的差异。
2. 学习Mybatis当中的设计模式。
3. 掌握Mybatis提供Plugin企业级别的开发。

源码地址：https://gitee.com/keyyds/mybatis-3.5.7

拉下来后跟Test案例打断点阅读即可

MyBatis主要解决了传统JDBC以下三大核心问题：

---

一、代码冗余与硬编码问题（JDBC的"重复劳动"困境）

• 传统JDBC痛点
  • 需要手动完成7个固定步骤（驱动加载→连接获取→Statement创建→结果集遍历→资源关闭等）
  • 每次操作需重复编写异常处理、事务控制代码
  • SQL与Java代码强耦合（如图中JDBC操作步骤直接嵌入业务逻辑）
• MyBatis的革新
  • 配置化：将SQL从Java代码抽离到XML文件（如图中create table user的SQL独立配置）
  • 模板化：通过SqlSessionFactory统一管理连接池，Executor封装执行流程
  • 动态代理：Mapper接口自动绑定XML中的SQL（图中"mapper接口"与XML的映射关系）

---

二、对象关系映射（ORM）的缺失（JDBC的"手动映射"难题）

• 传统JDBC痛点
  • 需手动遍历ResultSet，逐字段映射到Java对象（如图中JDBC步骤6的"处理结果集"）
  • 复杂对象（如嵌套对象、集合属性）映射需大量手写代码
  • 字段名与属性名不一致时需硬编码适配（如数据库user_name转Java的userName）
• MyBatis的革新
  • 自动化映射：通过反射机制自动填充POJO（如图中User类的id/name/age字段自动注入）
  • 灵活映射规则：支持驼峰命名转换、自定义ResultMap
  • 关联关系处理：通过<association>和<collection>标签实现对象嵌套查询

---

三、架构扩展性与维护性问题（JDBC的"低可维护性"缺陷）

• 传统JDBC痛点
  • SQL分散在代码中，修改需重新编译
  • 缺乏分层设计，业务逻辑与数据访问层混杂
  • 难以实现缓存、拦截器等扩展功能
• MyBatis的革新
  • 分层架构设计（如图中核心组件）：
    • Mapper中心化：面向接口编程，DAO层与SQL解耦
    • StatementHandler：解耦SQL预处理逻辑
    • ResultSetHandler：专业化结果集处理
  • 动态SQL支持：通过OGNL表达式实现条件分支、循环逻辑
  • 插件机制：基于责任链模式（Interceptor）扩展功能（如分页插件）

---

四、MyBatis诞生的核心设计哲学

1. 半自动化ORM定位
   • 既不像Hibernate全自动封装SQL，也不像JDBC完全手动控制
   • 保留SQL灵活性（如图中直接编写CREATE TABLE等原生SQL）
   • 通过XML配置实现SQL与代码分离（图中"配置文件"与Java类并行存在）
2. 轻量化与高扩展性
   • 核心组件（SqlSession、Executor等）通过工厂模式、动态代理实现松耦合
   • 仅需极少的依赖（如图中仅需JDBC驱动+配置文件即可运行）
3. 面向开发者体验优化
   • 通过"约定优于配置"简化开发（如自动匹配字段与属性名）
   • 提供SqlSession模板方法，隐藏底层JDBC复杂操作（如自动关闭连接）

---

五、历史背景的必然性

MyBatis（前身iBatis）诞生于2000年代初期，正值企业级Java应用爆发期：

• JDBC的局限性：面对复杂业务，纯JDBC开发效率低下
• 全自动ORM的不足：Hibernate等框架对复杂SQL支持不足
• 敏捷开发需求：需要快速响应需求变化的轻量级框架

MyBatis通过"SQL可控的ORM"定位，精准填补了市场空白，成为Java持久层框架的经典选择。