一、看法1
首先是运行速度,hibernate是在jdbc上进行了一次封装,而mybatis基于原生的jdbc,因此mybatis天生就有运行速度上的优势。
然后mybatis开放了插件接口。也许mybatis团队知道自己人少力单,索性把很多功能接口都开放了。不好分页?网上大神写的分页插件多得很;需要手写sql?按注解生成自动生成sql的插件早就有了;还有缓存的插件等等。可以说,只要肯在mybatis上花时间,你会发现orm这一块的所有问题它都有解决方案。这方面不是说hibernate不好,但是我还真没听说过hibernate有插件了。
还有就是对遗留系统的支持。很多系统在设计之初还没有orm思想,现在想“抢救”一下,用mybatis就比hibernate更合适。因为mybatis可以很容易做到不规范的映射对象和规范的映射对象共存,如果这种系统中再需要增加个需要复杂sql的功能,mybatis只需要把sql手写出来,先把功能运行起来后再看看能不能变成自动生成的sql,而对hibernate来说就很困难了。
其实我对两个框架的理解也不是很多,但是在说这个话题前我想先说说jvm的垃圾回收机制。jvm中的垃圾(内存)回收是通过垃圾回收器来处理的。而垃圾回收器是有很多种的,基于不同的算法,也各有优缺点。一般为了达到最优的效率,jvm不会只使用一种垃圾回收器,而是一般根据新生代和老年代的特性选择不同的回收器处理。而某些垃圾回收器更是针对自己的缺点在特殊情况下有其他算法的解决方案。
回到话题上,从设计上来说,Hibernate其实更加灵活多样,这种灵活不是指查询数据时的灵活(也就是Mybatis的优点),而是指在开发效率、便捷度与可控性、可选择性上的灵活,Hibernate本身支持多种查询,通过在不同场景下使用的H的不同查询方式,可以达到开发效率和性能间的一个均衡:在一些简单的查询的地方使用Hibernate的封装的面向对象查询方式,在一些业务复制,涉及到关联表多,数据量大的地方,使用效率最高的Native查询。这样就可以充分发挥不同查询的优点,进而降低各个查询方式的不足。这点其实跟垃圾回收的解决方案和思路上很类似。
Mybatis跟Hibernate的对比,和C语言跟Java的对比有点像,在早期Java内存回收以及效率还没上去的时候,很多人也不会觉得Java好,觉得它慢,可是Java有它的魅力所在,也就是跨平台性,随着后面Java体系慢慢成熟、硬件技术发展起来,在越来越多优秀方案用于解决Java效率问题上后,Java效率的也并没有成为它成为世界变最流行的语言的阻碍。在大部分的业务场景下,应用都可以使用Java进行开发使用,包括现在很多的大型的互联网网站。Hibernate的跨数据库特性和Java的跨平台很像。从C到Java是思想模式上的转变(面向过程到面向对象),最终带来了巨大的成功。从未来的发展上来看,Hibernate的设计思想(ORM)应该是一个趋势。甚至从数据库本身的发展来说,未来也可能出现从关系型数据库到对象型数据库的转变,毕竟现在已经有一些对象数据库开始流行并应用在一些业务场景中了。
而反观Mybatis,它查询数据时灵活和效率、同样也是一个短期或者长期内比较难赶超的优势,就像现在的对象语言虽然为主流,却不能取代完全过程语言一样。
最后我比较赞同一句话,存在即合理。既然两个框架都能成为流行的持久层框架,那么它们肯定有它们各自的过人之处。重点在于使用者如何去根据实际需求权衡选择适合的框架和设计而已。
以上论点可能有很多不准确的地方,因为我开发经验还很少,技术还很浅薄,对很多东西的了解都不够多与深入,个人观点,不对欢迎指正。
Mybatis只是一个半orm产品,除了灵活好学外各方面都不如Hibernate。用Mybatis之所以能流行起来有两个原因。适合初学者意淫是基础。第二。是bat喜欢使用。之于为为什么bat喜欢用是因为,以bat的流量已经到了要自己开发自己数据库以适应大规模集群的阶段。比如:阿里的核心数据库就是在开源的mysql上改过的。这种改过的数据库,Mybatis手写sql为核心的框架有天生的优势。
Hibernate全自动orm的优点在于会用的人拿它做项目,快速,高效,高度解耦。在项目开发,数据库结构不断变幻阶段,不知甩Mybatis几条街。但是,也是因为它全自动的优点,在计算机集群需要大量跨数据库事务的环境下是不如Mybatis灵活。
Mybatis只是一个小玩具,它有的功能,Hibernate也有。Hibernate也有自己拦截器,甚至可以在它生成的sql里像Mybatis加入自己的东西的。不过,一般没人,国内也没这类的教程。因为,这么用就失去了用Hibernate提高开发进度的本意。
单数据库下Hibernate无敌的存在,有怀疑的都是外行。集群下优点变缺点,但是,不是不能解决google有一个开源项目可缓解这个问题。只是比Mybatis复杂很多而已。所以,Hibernate特别适合那些有技术实力,项目处于开发期,数据层级不稳定的时期。
之于,数据量大了以后,真正上开始上集群。Mybatis这个小玩具开始上台的时候,其实,数据库技术其实已经不是核心,大数据跟no-sql会更好地解决问题。这一时候的db层,所有人的精力基本上也在hadoop跟spark上了。只会Mybatis在有点规模的互联公司,永远走不出非主流,小三的命运。
1、数据量、有以下情况的最好就用MyBatis
如果有超过千万级别的表,
如果有单次业务大批量数据提交的需求(百万条及其以上的),这个尤其不建议用hibernate
如果有单次业务大批量数据读取需求(百万条及其以上的)
2、表关联复杂度
如果主要业务表的关联表超过20个的(大概数量,根据表的大小不同有差异)不建议用hibernate
3、人员
如果开发成员多数不是多年使用hibernate的情况(一般开发水平评估),建议使用MyBatis
理想和现实是有差距的,把不是object的数据库结构映射,是一种leak abstraction
Hibernate用来做学校项目级别的不错,真正的项目一般都用mybatis,毕竟控制能力,调优成本更重要
hibernate的门槛比较高.老实说,真的会用hibernate,并且能在产品里驾驭的人很少很少.
后期每个人都恨不得杀了hi
Hibernate没有你说的这么简单和方便,如果是很简单的增删改查,而且不牵涉到多表关联,Hibernate会是好的选择,但是这样的情况很少吧。
我觉得HIbernate的有一下几个严重的缺点:
1. 多表关联等比较复杂,使用的成本并不低
2. 效率比较低,在大型项目中很少会使用到它,因为sql都是自动生成的,不太好进行人工的优化。调优需要丰富的经验,这些经验可能是需要被坑过很多次才知道
在下认为mybatis会有更强的掌控度,你可以控制sql,而不是hibernate那样使用hsql。你几乎无法预知生成的真正sql是什么样,多么烂。。
这个优点前期并不明显,尤其是表少,表关联少,数据量少的时候,因此这个阶段hibernate会更方便,但是一点复杂度到了一定程度,那mybatis的优越性就就来了,自己写sql,可控度非常高。效率也不会因为无法预计的sql而被拉低(不排除人为因素)。。
当然还有缓存啥的。。具体hibernate不了解,不做比较。
个人觉得仅从控制度和个人控制欲这一块,我就选择mybatis。
为什么我不把能掌控的东西都掌控在我自己的手里?
你们都忽略了一个要点:Hibernate/JPA 要长时间占用Connection,而且一不小心就写出个长事务,而MyBatis可以每条statement用一下Connection就还回去。
随借随还的模式更适合大规模高并发程序。
至于查询性能,如
还有个小众的Ebean ORM,综合了两者优点,效仿了RoR的Active Record,也很不错。