phpstudy集成环境

 首页 > 关于mybatis和hibernate的困惑

关于mybatis和hibernate的困惑

谢谢

hiberbate是用java对象拼sql，mybatis是直接写原生sql。前者开发一时爽，(修改)维护火葬场；后者需要对sql知识有一定了解(相比前者)，如果公司有DBA的话，他看原生sql比看java代码要直观得多。至于性能什么的大部分情况下都不用考虑(真要考虑的话可以去搜一下近年来有些人讨论过的“去ORM”)，最重要的是可维护性可维护性可维护性。

对比这两个之间的关系，从开发效率、可维护性、性能三个方面给出考虑。而就其重要性而言，在项目工程开发过程中，开发效率>可维护性>性能。可能对于某些业务来说，性能更关键，但放眼全局，个人觉得开发效率>可维护性>性能。

首先来说，开发效率。个人感觉如果你是做一些简单的CMS类似的只有简单的增删改查的项目，那么使用Hibernate更有优势，不需要掌握太多的Hibernate知识，只需要会一些基本的查询和一些配置（Hibernate真正要学会，个人感觉知识量比mybatis大很多）。hiberbate是用java对象拼sql，mybatis是直接写原生sql。hibernate提供了很好的映射机制，mybatis还需要自己写resultmap paramMap这些东西。Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询，Mybatis需要手动编写SQL语句，以及ResultMap。而Hibernate有良好的映射机制，开发者无需关心SQL的生成与结果映射，可以更专注于业务流程。综上所述，那么从开发效率上来讲，Hibernate> mybatis。

可维护性：hiberbate是用java对象拼sql，mybatis是直接写原生sql。直接写SQL更容易维护，而前者需要通过java对象来看SQL，你得把sql，用System.out.println(sql);把SQL打印出来，才可以看到。Hibernate的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段，但这样就破坏了Hibernate开发的简洁性。而Mybatis的SQL是手动编写的，所以可以按需求指定查询的字段。Hibernate HQL语句的调优需要将SQL打印出来，而Hibernate的SQL被很多人嫌弃因为太丑了。MyBatis的SQL是自己手动写的所以调整方便。但Hibernate具有自己的日志统计。Mybatis本身不带日志统计，使用Log4j进行日志记录。

性能：两者都提供了缓存，session机制。小项目两者差不多吧.大型项目mybatis>hibernate。

个人还觉得hibernate 好用呢，自动建表，性能问题是关联查询。

业务量比较小的话，就看你个人哪个比较熟练了。都可以。没必要为这个纠结。mybatis的灵活性要高些，给开发人员更多自己实现的空间。hibernate的关联应该是稍慢一点的原因。

hibernate学习成本比较高，但是j2ee里头有JPA规范，学习规范也还可以。mybatis就相对来说简单，容易上手，可控。hibernate学习成本高，过度面向对象，难以调优。至于使用的话，看个人了，对于toB或者toC的应用比较偏向mybatis，但是对于做管理后台这种，hibernate就可以

mb sql写到xml里面不也需要解析么，效率也高不到哪里去吧

知乎上也有类似的问题。
看到高票的回答大致就是说，hibernate比mybatis掌握难度要高一些，对sql的控制弱一些。

技术没有好坏，只有适不适合，在特定的情况下解决特定的问题。不同的人用hibernate,会产生不同的结果，如果你精通hibernate，性能一样不是问题。看到楼上说了那么多二者的比较，其实真的没有什么意义。

hibernate适合于都是单表的增删改差，开发效率很高，可是一旦业务扩展或者当初db设计不好，需要连表查询（因为hibernate的思想是对表的类化，但实际生活中要做到完全的类化在一个项目刚开始的时候是不容易做到的）不同的结果再加上删选匹配的话效率就会下降（除非你写sql，但是这样一来还不如一开始用mybatis），尤其再遇到大数据量，效率成倍数下降。
不超过100个用户？，这里的数量级不是按单表算的，单表如果超过一定数据量也不是简单选用hibernate或mybatis能解决的，只能说如果用mybatis的话比较好改而已。就我经验，如果涉及大量连表查询且业务复杂的时候（通常项目到最后都是如此）最好用mybatis，简单的还是hibernate快一些（开发效率）

hibernate、mybatis都只是对JDBC的封装，程序性能好不好，主要还是看SQL写得够不够优秀，DB设计是不是合理，当然hibernate不少SQL是用程序方式实现的，如果两个框架都很精通，使用起来性能上差别应该不大，那么问题来了，hibernate封装程度过高，想精通其实是挺困难的，mybatis则只是jdbc的简单封装，学习成本较低，而且hibernate很多场景下将sql封装起来了，如果不是特别精通的话，有些时候写出来的程序会出现预料不到的情况，mybatis则因为较简单，也没做太多的事，所以程序运行结果通常比较容易预料到可能出现的问题。
两个框架其实设计都很优秀，个人使用习惯反而更重要，习惯于mybatis的人，一般很难会再切换到hibernate的，反之如果真正精通hibernate的人，应该也不会刻意去使用mybatis(个人愚见)。

1. 问题1:什么样的情况下,Hibernate 会慢MyBatis10倍?

当Hibernate用错了的情况下,会出现:P
比如, Hibernate的对象A里的内嵌对象B加载被你从默认懒加载改为预加载(假设你没有搞懂影响,就改动了配置), 你要查询对象A的列表,就会出现N+1查询, 但你的大部分业务逻辑又不需要读取内嵌对象B,性能就会很差.
而一般情况下MyBatis, 这种查询是需要手写的. 出现这种情况的概率较小.

JPA(Hibernate)的内容涵盖真的很广,有很多优化技巧.想玩熟要花的成本不低.(我手头上那本Hibernate In Action厚度很的让人望而生畏, 花了好久才看完), 不知道有多少程序员是爱看书的且有这个耐心.

但是,MyBatis上手要容易多了. 虽然MyBatis在用错的情况下.性能会同样比Hibernate差好多倍.但MyBatis没那么复杂啊. 那出错的几率就小很多了.

2. 问题2:小项目用MyBatis还是Hibernate?

如果你对Hibernate很有研究兴趣,且想把他用熟.我建议拿你就试试呗. 毕竟大多数的项目是需要快速出成果的.
Hibernate在这方面比MyBatis简单多了(当然MyBatis有自动生成代码的方法,但相比还是麻烦不少).
如果后续项目发展的不错, 需要多人协作开发, 请务必让新手远离持久层代码逻辑.

学习阶段使用过，hibernate 个人的感受是封装的太死了。很多时候感觉带来的不是方便，而是我要为了“配合”这个框架做一些看起来不必要的操作。

可以尝试下：http://www.oschina.net/p/monalisa-core 配合Eclipse的插件使用更方便：

实际工作中都使用Mybatis基本上并不是基于性能或者可用性上的考量，而是基于个人习惯。
像我们这些老程序员，写SQL习惯了，不写就难受。相比之下过于自动化的hibernate会让我们感到恐慌。
仅此而已。

看大家讨论感觉mybaits更好一样，但当初一直以为hibernate更适合大型开发就直接走hibernate了。那时项目比较急，用得像mybatis一样，后来玩久了，发现很多有趣的东西，hibernate提供的经验简化了不少工作量和兼容性，但这些绝对需要有经验后才明白，加上后来有用上了hibernate search，全文检索，也就没法换了，反正写原生sql也可以hql也可以，xml配置工具也有，辅助注解也灵活，甚至还能产生原生sql不一样的one2many，many2many数据结构，总之就是太全面的一个大家伙了，还没遇到后悔的时候，就继续学吧。一般是用hibernate tools自动创建所有表的Java和xml的mapping做一般查删改，然后复制Java代码改名，用注解手工建关联，删除不需要的字段。

简单来说，Hibernate 是面向对象的，MyBatis 是面向 SQL 的。选哪个得看你的人员配置对哪个熟悉，业务会不会有很多复杂查询，对性能要求高不高。另外，很多时候都是对 Hibernate 不熟悉，所以会觉得 Hibernate 做不了这个事情，或者做起来很复杂。Hibernate 表示这锅我不背。。。

谢邀！下面的回答说的都挺好的，一是MyBatis学起来简单，二是灵活，直接写SQL易于掌控，至于性能都不是什么重点，开发效率、可维护性什么的比性能要重要的多。

现在开发一边采用逻辑外键,不进行表关联,开发效率都差不多,mybatis简单,清晰,sql更具通用性,协作稍微方便点.

总的来说hibernate不够灵活，封装的太深了。mybatis可以随心所欲的配置想要的操作

【热门文章】
【热门文章】