ibatis

iBATIS一词来源于“internet”和“abatis”的组合，是一个由Clinton Begin在2001年发起的开放源代码项目。于2010年6月16号被谷歌托管，改名为MyBatis。是一个基于SQL映射支持Java和.NET的持久层框架。相对Hibernate和Apache OJB 等“一站式”ORM解决方案而言，ibatis 是一种“半自动化”的ORM实现。[1]

相关介绍

BATIS一词来源于“internet”和“abatis”的组合，是一个由Clinton Begin在2001年发起的开放源代码项目。

一站式

iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的JPetStore实例。相对Hibernate和ApacheOJB等“一站式”ORM解决方案而言，ibatis 是一种“半自动化”的ORM实现。

ibatis框架

iBATIS 提供了三种语言实现的版本，包括：Java、.NET以及Ruby。

主流

所谓“半自动”，可能理解上有点生涩。纵观主流的 ORM，无论 Hibernate 还是Apache OJB，都对数据库结构提供了较为完整的封装，提供了从POJO到数据库表的全套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过 Hibernate或者OJB 提供的方法完成持久层操作。程序员甚至不需要对 SQL 的熟练掌握，Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的 SQL 并调用 JDBC 接口加以执行

大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。

开发

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

开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交通银行，都在开发规范中严格指定）

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

半自动化

“半自动化”的ibatis，却刚好解决了这个问题。这里的“半自动化”，是相对Hibernate等提供了全面的数据库封装机制的“全自动化”

ORM 实现而言，“全自动”ORM 实现了 POJO 和数据库表之间的映射，以及 SQL 的自动生成和执行。而ibatis 的着力点，则在于POJO 与 SQL之间的映射关系。也就是说，ibatis并不会为程序员在运行期自动生成 SQL 执行。具体的 SQL 需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定 POJO。

通常在如下场景和条件下，选择ibatis, 将更有助于发挥ibatis在持久层的优越性：

1. 知道怎样操作10种以上的数据库

2. 可配置的caching(包括从属)

3. 支持DataSource、local transaction management和global transaction

4. 简单的XML配置文档

5. 支持Map, Collection, List和简单类型包装(如Integer, String)

6. 支持JavaBeans类(get/set 方法)

7. 支持复杂的对象映射(如populating lists, complex object models)

8.对象模型从不完美(不需要修改)

9. 数据模型从不完美(不需要修改)

10. 你已经知道SQL，为什么还要学习其他东西

优点缺点

优点：

1、减少代码量，简单；

2、性能增强；

3、Sql语句与程序代码分离；

4、增强了移植性；

缺点：

1、和Hibernate相比，sql需要自己写；

2、参数数量只能有一个，多个参数时不太方便。

发展

ibatis本是apache的一个开源项目，2010年这个项目由apache software foundation 迁移到了google code，并且改名为mybatis。