iBATIS与Hibernate数据库映射框架
2010-07-05 11:51
323 查看
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 进行数据库操作实际上也是不错的选择,只是拖沓的数据库访问代码,乏味的字段读取操作令人厌烦。
“半自动化”的 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 的出现显得别具意义。
相对 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 的出现显得别具意义。
相关文章推荐
- JDO、EJB/CMP、Hibernate和Amber等数据库映射操作等框架的比较
- Ibatis和Hibernate 数据库分表(动态表名映射)的实现方法
- Ibatis和Hibernate 数据库分表(动态表名映射)的实现方法
- Ibatis和Hibernate 数据库分表(动态表名映射)的实现方法
- ibatis框架,数据库的字段和实体类的字段映射
- ibatis框架,数据库的字段和实体类的字段映射
- Ibatis和Hibernate 数据库分表(动态表名映射)的实现方法
- 数据库持久层框架iBatis、myBatis、Hibernate对比
- Hibernate框架学习(三) 关系映射
- 同一个数据库实例,不同用户下多表创建视图,Hibernate完成ORM映射,Spring整合,后台实现
- Hibernate数据库持久层框架
- 详谈Hibernate框架关系映射!
- 深入分析 iBATIS 框架之系统架构与映射原理
- 18.C#:VS2010之EF框架添加edmx(自动跟踪实体生成器):映射到数据库表和代码实体类
- hibernate指定属性不映射到数据库里
- Hibernate框架学习之注解映射实体类
- Hibernate框架学习之注解映射实体类
- Android数据库hibernate框架
- 深入分析 iBATIS 框架之系统架构与映射原理【转】
- 【hibernate框架】关系映射之一对一单项外键关联(Annotation实现)