Question

Java的持久层Hibernate毫无缺点Mybatis弱爆了

很多大型项目持久层都是用的Hibernate，功能强大，操作对象，作为一个资深的java程序员，没有比hibernate更好用的，我想说mybatis弱爆了，因为你不会hibernate所以才会用mybatis小儿化的框架，我现在追求的是效率，mybatis只是停留在sql上，会消耗大量的时间写sql,而我的问题就是，新兴的互联网APP的java后台用mybatis好还是hibernate，如果你是一个java工程师那么说出你的观点，来说服我！

Answer 1

有这时间，还不如多看点书

追问

有那时间还不如说点有用的？如果前期没有选好一个，后期问题只会越来越多。只有两个都了解才可以做取舍，问问题的目的就是想做一个取舍

Answer 2

hibernate的优点 : 解决了直接用JDBC操作数据库的烦琐操作。屏蔽了各种数据库的实现细节。
现有ORM框架或ORM相关框架主要有Hibernate，Mybatis。这两个框架本来是为了解决直接用JDBC操作数据库带来的烦锁重复工作，但它们却引起了其它的问题。有人报怨Mybatis，很简单的操作，都要写sql语句；有人报怨当用户要用自定义sql的方式时Hibernate是如何的难用，要想熟悉Hibernate是如何的困难。从另一方面来说，Hibernate的流行，除了出现较早，《expert one-on-one J2EE Development without EJB》一书的推荐也功不可没，还有就是因为它操作单表时确实比直接用JDBC省事；而Mybatis的流行，也印证了贴近原生sql的方式很受欢迎(即使最近几年NOSQL产品很火爆)。但不管用这二者中的哪个，都让人有些缺失的遗憾，以致于有人想要同时使用这两个框架。除此之外，它们的编码复杂度为O(n)，也就是说每操作一个DB的表，就要写一次dao。
-------------------
1) 对于每个实体，需要写一个dao接口文件。编码复杂度C(n)=O(n)，即会随实体的增长，编码量呈线性增长。当n较大时，会增加许多人力物力消耗。
2) 实体Javabean与DB表的map映射文件太多；或者，实体Javabean文件注解用得太泛滥，太多注解难以记忆，增加开发人员负担。Mybatis中实体对应的mapper文件，代码太多，虽然可以自动生成，但阅读性太差。编写和调试sql语句需要大量时间，降低开发效率。
3) 实体操作默认的条件，一般以id作为条件，但开发时，一般不会提前知道id；若用其它条件作为查询等，需要在接口文件新定义方法。如一个实体有10个字段，2个字段组合一个查询方法，则有 =45个查询方法；若算上3个字段，4个字段的组合，则更多。
4) 接口文件定义好后，若后期发现定义的方法不能满足需求，需要定义新的方法，又要修改接口文件；若是系统已经上线，还要需要重新开发、测试、发布等。
5) 当一个表新增一个字段，删除一个字段，或修改一个字段时，Mybatis需要修改mapper映射文件，几乎其中的每个方法都要修改。修改字段，Mybatis在编译期不能自动发现错误。Hibernate通过xml文件或有注解的Javabean文件，同步DB的表结构时，也不能实现删除和更新。更新时，它是忽略原来的字段，然后新增一个字段，除非删除了表，重新再建一次。要是DB的表已保存了数据，不能删除，还是要手动去更改数据库。
6) Hibernate想让ORM框架做完DB所有的事情，反而使框架变得太复杂，不易于使用。Hibernate的ORM模型不能查询一部分数据，即使用户没有使用到，也会将所有关联的数据都查询出来。
7) Hibernate的概念太复杂，学习成本高，更新会先查询再更新，n+1问题。Mybatis即使进行单表的Suid操作也需要人工写sql或生成sql文件，需要维护的sql太多。
8) 需要写很多的判断字段是否为空（null) ，是否是空字符串的语句；开发人员需要承担太多类似的重复，乏味的编程工作。
---------------------
来源：CSDN
原文：https://blog.csdn.net/abckingaa/article/details/84557336