Ibatis入门

ibatis 开发指南

IBATIS就是我们通常所说的数据映射器，所谓映射层，是用于在对象和数据库之

间搬运数据，同时保证对象，数据库以及映射器本身都相互独立。

相对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
进行数据库操作实际上也是不错的选择，只是拖沓的数据库访问代码，乏味的字段读取操作
令人厌烦。
“半自动化”的ibatis，却刚好解决了这个问题。
这里的“半自动化”，是相对Hibernate 等提供了全面的数据库封装机制的“全自动化”
ORM 实现而言，“全自动”ORM 实现了POJO 和数据库表之间的映射，以及SQL 的自动
生成和执行。而ibatis 的着力点，则在于POJO 与SQL 之间的映射关系。也就是说，ibatis
并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映
射配置文件，将SQL 所需的参数，以及返回的结果字段映射到指定POJO 。
使用ibatis 提供的ORM 机制，对业务逻辑实现人员而言，面对的是纯粹的Java 对象，
这一层与通过Hibernate 实现ORM 而言基本一致，而对于具体的数据操作，Hibernate
会自动生成SQL 语句，而ibatis 则要求开发者编写具体的SQL 语句。相对Hibernate 等
“全自动”ORM 机制而言，ibatis 以SQL 开发的工作量和数据库移植性上的让步，为系统
设计提供了更大的自由空间。作为“全自动”ORM 实现的一种有益补充，ibatis 的出现显

得别具意义。

与其它解决方案相同的优点：

          （1）存储过程：IBATIS对SQL进行了封装和外部化，使SQL从你的应用程序代码中

                    分离出来。IBATIS具有与存储过程相似的API，但IBATIS的这些API是面向对象

                    的。IBATIS也完全支持对存储过程的直接调用。

          （2）内联SQL：IBATIS允许SQL以其最自然的方式书写。没有字符串拼接，没有参

                    数“设置”，没有结果“获取”。

          （3）动态SQL：IBATIS提供了若干特性以支持基于参数的动态构建查询。不需要“

                   查询构建工具“这样的API。

           （4）O/RM：IBATIS支持许多O/RM工具一样的特性，例如延时加载，连接抓取，

                    高速缓存，运行时代码生成以及继承。

           （5）业务逻辑从数据库中分离出来，应用程序更容易部署与测试，也具有更好的

                     可移植性。

            （6）IBATIS对应用程序代码没有任何影响。不需要任何预编译器，并且你能够完

                     全访问SQL的所有特性，而不只是一个子集。

             （7）IBATIS不要求SQL被写成一堆字符串的拼接，中间还夹杂着应用程序的代码。

             （8）IBATIS可用于任意数据库模型与任意对象模型的组合。它对这两者中的任何

                      一个的设计没有任何约束和要求。

优点：

              （1）小巧，移植性好。

              （2）据官方说减少了63%数据访问层代码量。

不适合使用：

          （1）当你永远拥有完全控制权时：如果能够保证拥有对应用程序设计和数据库设计

                   的完全控制权，那你的确非常幸运。这在商业环境或者任何一个核心工作不是

                  软件开发的行业中都是非常少见的。

                  当你具有完全控制权时，就有充分理由使用一个完全的对象/关系映射方案，如

                  Hibernate。你可以充分利用对象/关系映射工具所能提供的设计优势并提高生产

                  效率。可能根本没有来自企业数据库小组的干扰，也不需要与遗留系统整合。

        （2）当应用程序需要完全动态的SQL时：如果应用程序的核心功能是动态生成SQL，

                   那么IBATIS就是错误的选择。IBATIS支持非常强大的动态SQL特征，这些特征又

                   反过来支持高级查询能力，甚至一些动态更新功能。然而，如果系统中的每个语

                  句都是动态地生成的，那么最好使用原始的JDBC，甚至可以创建自已的框架。

        （3）当没有使用关系型数据库时：对于关系型数据库之外的其他数据库，之外的其

                  他数据库，也存在可用的JDBC驱动程序。对于平板文件，微软的EXCEL电子表

                  格，XML，以及其他类型的数据存储平台，都有相应的JDBC驱动程序。虽然一些

                  人在IBATIS中使用这些驱动程序也获得成功，但是对于大多数用户我们并不推荐使

                  用这些驱动程序。

          （4）当IBTIS不起作用时：IBATIS也不断地实现了许多非常好的特性。然而IBATIS有其自已

                   的发展方向和设计目标。因此它有时候就有可能会同一些应用程序的需求发生冲突。

                   人们在软件帮助下可以完成很多神奇的事情，但是有时候由于需 求过于复杂，软件可

                  能完全不起作用IBATIS也是如此。

具体实现步骤：

            （1）编写XML数据映射文件，并且在文件中编写好SQL语句。

            （2）编写SqlMapConfig.xml数据库连接文件。

            （3）编写代码

                      Reader reader = Resources.getResourceAsReader("com/iflytek/entity/SqlMapConfig.xml");

                      sqlMapClient = SqlMapClientBuilder.buildSqlMapClient(reader); 

                      得到sqlMapClient 对象，通过该对象操作数据库，sqlMapClient对象中有相应的CRUD方法。