大家好！今天笔者和大家一起分析下为什么选择MyBatis作为应用和数据库之间的中间层？MyBatis在其中起到承上启下的作用，不难发现，在多数的架构和代码设计中，往往通过增加一层抽象层，屏蔽两边的细节，能够提升软件的可扩展性。但MyBatis并不是唯一一个提供这一功能的架构，那为什么选择它呢？
背景
在绝大多数在线应用场景中，数据总是存储在关系型数据库中的，虽然有时会将其他持久化存储（如 ElasticSearch、HBase、MongoDB 等）作为辅助存储，但可以发现在如今的大数据时代，关系数据库依然是存储数据的主力军。
开发过程中应用往往是无状态的，提供多样性服务的通常取决于数据，因而，开发过程中常常需要与数据打交道，而关系型数据库产品又有SQL Server、MySQL、Oracle 等。在业务开发的过程中，常常会进行如下流程：
- 使用的是面向对象的思维去实现业务逻辑；
- 在设计数据库表的时候，考虑的是第一范式、第二范式和第三范式；
- 在操作数据库记录的时候，使用 SQL 语句以及集合思维去考虑表的连接、条件语句、子查询等的编写。
可以发现上述过程有很多可重复的部分，为了提高复用性，对这个过程进行抽象化，并通过设计模式来屏蔽实际操作的不同，使得整个过程能够通过ORM（Object Relational Mapping，对象-关系映射） 框架来应对不同的数据库产品，提高软件的robust。
为什么选MyBatis
Apache 基金会中的iBatis项目是MyBatis的前身，2010年更名为MyBatis，并在2013年将源代码迁移到了GitHub。
优点
-
可以帮助 Java 开发封装重复性的 JDBC 代码。 通过 Mapper 映射配置文件以及相关注解（在没有自定义
objectFactory的时候，使用的是内置的default ObjectFactory），将 ResultSet 结果映射为 Java 对象，在具体的映射规则中可以嵌套其他映射规则和必要的子查询，这样就可以轻松实现复杂映射的逻辑，并且能够实现一对一、一对多、多对多关系映射以及相应的双向关系映射。 -
MyBatis 相较于 Hibernate 和各类 JPA 实现框架更加灵活、更加轻量级、更加可控。 我们可以在 MyBatis 的 Mapper 映射文件中，直接编写原生的 SQL 语句，应用底层数据库产品的功能，使我们能够直接优化 SQL 语句，使之能按照数据库的使用规则，让原生 SQL 语句选择我们期望的索引，从而保证服务的性能，这就特别适合大数据量、高并发等需要将 SQL 优化到极致的场景；
-
MyBatis 提供了强大的动态 SQL 功能来帮助我们开发者摆脱这种重复劳动。我们只需要在映射配置文件中编写好动态 SQL 语句，MyBatis 就可以根据执行时传入的实际参数值拼凑出完整的、可执行的 SQL 语句。
-
强大的插件支持，让程序员不需要学习MyBatis框架也能迅速上手使用。比如MyBatis Generator。
总结
MyBatis 通过把程序员从重复的代码中解放出来，更加专注于业务逻辑的实现，并且留有接口进行数据库操作优化，使得业务需求能够最大限度地满足，加之强大的插件支持，大大提高了我们的开发效率。但我们依然要去借鉴框架的思想，去写出更好的业务代码以及提升自己的能力。
