ibatis基本内容简介

本文介绍了iBatis(现称MyBatis)的发展历程及其与Hibernate这两种持久层框架的区别与联系。iBatis允许开发者编写自定义SQL,适合需要高度优化SQL性能的场景;而Hibernate则提供了一种更为自动化的ORM解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    iBATIS一词来源于“internet”和“abatis”的组合,是一个由Clinton Begin在2002年发起的开放源代码项目。于2010年6月16号被

谷歌托管,改名为MyBatis。是一个基于SQL映射支持Java和·NET的持久层框架。这里我们主要讲解ibatis也可称为MyBatis在Java上面

的具体应用。

     iBATIS提供的持久层框架包括SQL Maps和Data Access Objects(DAO)。

     相对于Hibernate和ApacheOJB等“一站式”ORM解决方案而言,ibatis 是一种“半自动化”的ORM实现。

     iBATIS 目前提供了三种语言实现的版本,包括:Java、.NET以及Ruby。下图是iBATIS的架构图

      

目前主流

     所谓“半自动”,可能理解上有点生涩。纵观目前主流的 ORM(对象关系映射),无论 Hibernate还是Apache OJB,都对数据库结构提供了
较为完整的封装,提供了从POJO到数据库表的全套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系,即可通过 Hibernate
或者OJB 提供的方法完成持久层操作。程序员甚至不需要对 SQL 的熟练掌握,Hibernate/OJB 会根据制定的存储逻辑,自动生成对应的 SQL
并调用 JDBC 接口加以执行。
      大多数情况下(特别是对新项目,新系统的开发而言),这样的机制无往不利,大有一统天下的势头。但是,在一些特定的环境下,这种一
站式的解决方案却未必灵光。

全自动ORM的缺陷

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

iBatis和Hibernate的区别和联系

iBatis和Hibernate之间有着较大的差异,但两者解决方案很好,因为他们有特定的领域。 我个人建议使用iBATIS的,如果: 你想创建

自己的SQL,并愿意维持他们. 你的环境是由关系数据模型驱动的。 你的项目工作有复杂架构的。

简单地要使用Hibernate,如果: 你的环境是由对象模型驱动的,并希望自动生成的SQL。

要说明的一些区别: iBATIS : 简单  更快的开发时间 灵活 封装尺寸更小 Hibernate: 为你生成SQL,这意味着你不用花时间在SQL上,

提供了许多更先进的高速缓存,高可扩展性

另一个重要的区别是,iBATIS利用SQL语句可能是依赖数据库,使用Hibernate的HQL是相对独立于数据库,它是更容易改变数据库。

Hibernate映射的Java作为POJO对象,iBatis将ResultSet映射,从JDBC API给出POJO OBJETS的数据库表。

如果您使用存储过程,那么在Hibernate中可以做到这一点,但它在iBATIS比较有点困难。作为一种替代的解决方案iBATIS的映射结果

集对象,所以没必要去关心表结构。这非常适用于存储过程,非常适用于报表应用程序等 最后,Hibernate和iBATIS的都是开源的对象

关系映射(ORM)在同行业中可用的工具。使用这些工具的取决于你。 Hibernate和iBatis两者也有来自Spring框架的良好支持,以便

它不应该是一个问题,选择其中之一。

 

iBatis的基本概念的讲解就先到这里(其实就是copy百度百科的哈~),下一篇我们将要讲解iBatis的具体使用过程
这个可是货真价实的东西了~~你懂的~
好吧,今天就先到这里吧~

 

 
 
 
 
 

 

转载于:https://www.cnblogs.com/xiohao/p/4379290.html

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值