hibernate和ibatis的对比

iBATIS是一个由Clinton Begin在2001年发起的开放源代码项目,最初侧重于密码软件的开发,现已成为一个基于Java的持久层框架。与Hibernate等一站式的ORM解决方案不同,iBATIS更倾向于半自动化的ORM实现,它要求开发者手动编写SQL语句,并通过映射配置文件将SQL所需的参数及返回结果字段映射到指定的POJO。


ibatis

求助编辑百科名片
iBATIS   
iBATIS

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, 将更有助于发挥ibatis在 持久层的优越性:
  1. 知道怎样操作10种以上的数据库
  2. 可配置的caching(包括从属)
  3. 支持DataSource、local transaction management和global transaction
  4. 简单的XML配置文档
  5. 支持Map, Collection, List和简单类型包装(如Integer, String)
  6. 支持JavaBeans类(get/set 方法)
  7. 支持复杂的 对象映射(如populating lists, complex object models)
  8. 对象模型从不完美(不需要修改)
  9. 数据模型从不完美(不需要修改)
  10. 你已经知道SQL,为什么还要学习其他东西

全自动

  使用ibatis 提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的 Java 对象
  这一层与通过 Hibernate 实现 ORM 而言基本一致,而对于具体的数据操作,Hibernate
  会自动生成SQL 语句,而ibatis 则要求开发者编写具体的 SQL 语句。相对Hibernate等
  “全自动”ORM机制而言,ibatis 以 SQL开发的工作量和数据库移植性上的让步,为系统
  设计提供了更大的自由空间。作为“全自动”ORM实现的一种有益补充,ibatis 的出现显
  得别具意义。

编辑本段发展

  ibatis本是apache的一个开源项目,2010年这个项目由apache software foundation 迁移到了google code,并且改名为mybatis。
扩展阅读:

内容概要:本文介绍了一个基于多传感器融合的定位系统设计方案,采用GPS、里程计电子罗盘作为定位传感器,利用扩展卡尔曼滤波(EKF)算法对多源传感器数据进行融合处理,最终输出目标的滤波后位置信息,并提供了完整的Matlab代码实现。该方法有效提升了定位精度与稳定性,尤其适用于存在单一传感器误差或信号丢失的复杂环境,如自动驾驶、移动采用GPS、里程计电子罗盘作为定位传感器,EKF作为多传感器的融合算法,最终输出目标的滤波位置(Matlab代码实现)机器人导航等领域。文中详细阐述了各传感器的数据建模方式、状态转移与观测方程构建,以及EKF算法的具体实现步骤,具有较强的工程实践价值。; 适合人群:具备一定Matlab编程基础,熟悉传感器原理滤波算法的高校研究生、科研人员及从事自动驾驶、机器人导航等相关领域的工程技术人员。; 使用场景及目标:①学习掌握多传感器融合的基本理论与实现方法;②应用于移动机器人、无人车、无人机等系统的高精度定位与导航开发;③作为EKF算法在实际工程中应用的教学案例或项目参考; 阅读建议:建议读者结合Matlab代码逐行理解算法实现过程,重点关注状态预测与观测更新模块的设计逻辑,可尝试引入真实传感器数据或仿真噪声环境以验证算法鲁棒性,并进一步拓展至UKF、PF等更高级滤波算法的研究与对比
内容概要:文章围绕智能汽车新一代传感器的发展趋势,重点阐述了BEV(鸟瞰图视角)端到端感知融合架构如何成为智能驾驶感知系统的新范式。传统后融合与前融合方案因信息丢失或算力需求过高难以满足高阶智驾需求,而基于Transformer的BEV融合方案通过统一坐标系下的多源传感器特征融合,在保证感知精度的同时兼顾算力可行性,显著提升复杂场景下的鲁棒性与系统可靠性。此外,文章指出BEV模型落地面临大算力依赖与高数据成本的挑战,提出“数据采集-模型训练-算法迭代-数据反哺”的高效数据闭环体系,通过自动化标注与长尾数据反馈实现算法持续进化,降低对人工标注的依赖,提升数据利用效率。典型企业案例进一步验证了该路径的技术可行性与经济价值。; 适合人群:从事汽车电子、智能驾驶感知算法研发的工程师,以及关注自动驾驶技术趋势的产品经理技术管理者;具备一定自动驾驶基础知识,希望深入了解BEV架构与数据闭环机制的专业人士。; 使用场景及目标:①理解BEV+Transformer为何成为当前感知融合的主流技术路线;②掌握数据闭环在BEV模型迭代中的关键作用及其工程实现逻辑;③为智能驾驶系统架构设计、传感器选型与算法优化提供决策参考; 阅读建议:本文侧重技术趋势分析与系统级思考,建议结合实际项目背景阅读,重点关注BEV融合逻辑与数据闭环构建方法,并可延伸研究相关企业在舱泊一体等场景的应用实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值