1.1 iBATIS概论

iBATIS Database Layer架构自2001年发展以来，至今已经成为Apache的官方项目。在iBATIS创始人的《iBATIS实战》一书中已经对iBATIS的定位做了一个明确的说明。iBATIS是一种Data Mapper，那什么又是Data Mapper呢？Martin Fowler在他的《Patterns of Enterprise Application Architecture》一书中是这样描述Data Mapper的：一个映射层，在对象和数据库间传递数据，并保持两者与映射层本身相独立。所以说，Mapper是在两个独立对象间建立通信关系的一种对象。

通过对程序源码的分析，iBATIS也具备了ORM框架的一些基本特性，但实际上iBATIS更像是一个SQL工具。同时，iBATIS不是直接在类与数据表或字段与列之间进行关联，而是把SQL语句的参数（parameter）和返回结果（result）映射至实体类（或JavaBean）。iBATIS是处于实体类和数据表之间的一个中间层，这使得它在类和数据表之间进行映射时更加灵活，而不需要数据库模型或对象模型（Object Model）的任何修改。我们所说的中间层实际上就是SQL映射层，它使得iBATIS能够更好地分离数据库和对象模型的设计，这样就相对减少了两者间的耦合。

相对Hibernate和Apache OJB等“一站式”ORM对象关系映射解决方案而言，iBATIS是一种“半自动化”的ORM实现。这里要说明一下“全自动化”和“半自动化”在实现ORM模式上的区别。

Hibernate和Apache OJB都是对数据库结构提供了较为完整的封装.提供了从POJO（Plain Old Java Objects普通Java对象）到数据库表的全套映射机制。软件开发人员往往只需定义好了POJO到数据库表的映射关系，即可通过Hibernate或者OJB提供的方法完成持久层操作，软件开发人员甚至不需要对SQL的熟练掌握。Hibernate、Apache OJB会根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口去执行。我们把这种模式称为“全自动化”模式。

“半自动化”ORM框架是相对上述提到的Hibernate等提供了全面的数据库封装机制的“全自动化”ORM实现而言，“半自动化”ORM框架重点在于POJO与SQL之间的映射关系。也就是开发人员编写SQL语句，通过映射配置文件，将SOL所需的参数，以及返回的结果字段映射到指定的POJO。这些过程全是手工来进行操作。iBATIS就属于“半自动化”ORM。

“全自动”ORM机制在大多数情况下有很大的优势。但是，也有一些特定的环境，这种一站式的解决方案却未必是最佳的选择。在现实中，这些特定的环境条件具有如下的特点：

① 数据库系统对于开发人员并不是完全控制的。处于安全考虑，也许只有部分数据或者局部权限开放给开发人员。只对开发团队提供几条Select SQL或存储过程以获取所需数据，具体的表结构不予公开。

② 为了提高系统的性能和实现分层开发，必须由数据库层的存储过程来实现所有的业务逻辑部分。

③ 对于一些系统，由于表与表之间主键和外键的约束关系复杂，这造成了生成标准POJO对象之间的关系也比较复杂，但是可以通过多种复合SQL可以编写出比较简洁高效的语句来实现多表关联查询。

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

面对这样的需求。如果再使用Hibernate这种数据访问策略来实现对数据库的访问就显得很不明智了。此时“半自动化”的iBATIS，却刚好解决了这个问题。

当然，iBATIS的ORM模式也并不是没有缺陷。首先，对于开发人员是增加工作量。iBATIS并不会为开发人员在运行期自动生成SQL语句执行，具体的SQL语句需要开发人员编写。其次，对开发人员的要求要高一点，毕竟要求开发人员对SQL语句要有一定的要求。最后，iBATIS支持的SQL是标准规范的SQL，可以在所有支持标准SQL的数据库系统中移植和运行。但是针对一些对标准SQL有扩展的SQL，如T-SQL、PL SQL等，则缺乏对扩展部分的支持。

在iBATIS创始人的《iBATIS实战》一书中，也专门提到了iBATIS的不适合环境。其中iBATIS不适合的三种环境为：① 当对数据库永远拥有完全控制权；② 当应用程序需要完全动态的SQL语句；③ 当数据是非关系数据库时。