相对Hibernate和Apache OJB 等“一站式”ORM解决方案而言，ibatis 是一种“半
自动化”的ORM实现。
大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一
统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。
在笔者的系统咨询工作过程中，常常遇到以下情况：
1． 系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几
条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。
2． 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由
存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交
通银行，都在开发规范中严格指定）
3． 系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高
度优化的SQL语句（或存储过程）才能达到系统性能设计指标。
面对这样的需求，再次举起Hibernate 大刀，却发现刀锋不再锐利，甚至无法使用，
奈何？恍惚之际，只好再摸出JDBC 准备拼死一搏……，说得未免有些凄凉，直接使用JDBC
进行数据库操作实际上也是不错的选择，只是拖沓的数据库访问代码，乏味的字段读取操作
令人厌烦。
“半自动化”的ibatis，却刚好解决了这个问题。
这里的“半自动化”，是相对Hibernate等提供了全面的数据库封装机制的“全自动化”
ORM 实现而言，“全自动”ORM 实现了POJO 和数据库表之间的映射，以及SQL 的自动
生成和执行。而ibatis 的着力点，则在于POJO 与SQL之间的映射关系。也就是说，ibatis
并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映
射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。
