?

iBATIS 一词来源于“ internet ”和“ abatis ”的组合，是一个由 Clinton Begin 在2001 年发起的开放源代码项目。最初侧重于密码软件的开发，现在是一个基于 Java 的持久层框架。 iBATIS 提供的持久层框架包括 SQL Maps 和 Data Access Objects （ DAO ），同时还提供一个利用这个框架开发的 JPetStore 实例。

相对 Hibernate 和 Apache OJB 等“一站式” ORM 解决方案而言， iBATIS 是一种“半自动化”的 ORM 实现。

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

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

在平时使用过程中，常常遇到以下情况：

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

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

3 ．系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的 SQL 语句（或存储过程）才能达到系统性能设计指标。面对这样的需求，再次举起 Hibernate 大刀，却发现刀锋不再锐利，甚至无法使用，奈何？恍惚之际，只好再摸出 JDBC 准备拼死一搏，说得未免有些凄凉，直接使用 JDBC 进行数据库操作实际上也是不错的选择，只是拖沓的数据库访问代码，乏味的字段读取操作令人厌烦。

“半自动化”的