MyBatis是一个支持普通SQL查询,存储过程和高级映射的优秀持久层框架.MyBatis去掉了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装.MyBatis可以使用简单的XML或注释进行配置和原始映射,以将接口和JAVA的POJO(Plain Old Java Objects,普通Java对象)映射成数据库中的记录.

MyBatis作为持久层框架,其主要思想是将程序中的大量SQL语句剥离出来,配置在配置文件中,以实现SQL的灵活配置.这样做的好处是将SQL与程序代码分离,做到可以在不修改程序代码的情况下,直接在配置文件中修改SQL.

纵观目前主流的ORM,无论是Hibernate还是JPA,都对数据库结构提供了较为完整的封装,提供了从POJO(Plain Old Java Objects)到数据库表的全套映射机制.程序员往往只需定义好POJO到数据库表的映射关系,即可通过Hibernate或者JPA提供的方法完成持久层操作.程序员甚至不需要熟练掌握SQL,Hibernate/JPA会根据制定的存储逻辑,自动生成对应的SQL并调用JDBC接口加以执行.

大多数情况下,这样的机制无往不利,但是,在一些特定的环境下,Hibernate这种一站式解决方案却未必适合:

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

开发规范中要求,所有牵涉业务逻辑部分的数据库操作,必须在数据库层由存储过程实现

系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL(或存储过程)才能达到系统性能设计指标.

面对这样的需求,Hibernate不再适合解决上述问题,甚至无法使用他.此时,直接使用JDBC进行数据库操作实际上也是不错的选择,只是拖沓的数据库访问代码,乏味的字段读取操作令人厌烦,而半自动化的MyBatis,却正好解决了这个问题.

这里的半自动化是相对Hibernate等提供全面的数据库封装机制的全自动化ORM实现而言的.全自动ORM实现了POJO和数据库表之间的映射,以及SQL的自动生成和执行.而MyBatis的着力点,则在于POJO与SQL之间的映射关系,也就是说,使用MyBatis提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的Java对象,这一点与通过Hibernate实现的ORM而言基本一致.而对于具体的数据操作,Hibernate会自动生成SQL语句,而MyBatis这不会为程序员在运行期间自动生成SQL执行.具体的SQL需要程序员编写,然后通过映射配置文件,将SQL所需的参数及返回的结果字段映射到指定POJO.

相对Hibernate等全自动ORM机制,MyBatis以SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更自由的空间.作为全自动ORM实现的一种有益补充,MyBatis的存在具有特别的意义.