国内为什么很少hibernate（现在java开发中，hibernate还用吗mybatis是不是已经取代了hibernate了）

本文目录

• 现在java开发中，hibernate还用吗mybatis是不是已经取代了hibernate了
• ibatis 比较起hibernate更垃圾，但为什么还会有这么多人用
• hibernate有没有实现接口
• 为什么要学习Hibernate
• 直接使用 hibernate 的人多， 还是用hibernate JPA实现的人多两者性能上、功能上有多大区别么
• 为什么很多人不愿意用hibernate了
• 做网站用hibernate的利与弊

现在java开发中，hibernate还用吗mybatis是不是已经取代了hibernate了

Hibernate功能强大，数据库无关性好，O/R映射能力强，如果你对Hibernate相当精通，而且对Hibernate进行了适当的封装，那么你的项目整个持久层代码会相当简单，需要写的代码很少，开发速度很快，非常爽。
Hibernate的缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，以及怎样用好Hibernate方面需要你的经验和能力都很强才行。
iBATIS入门简单，即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使用经验，对于没有那么高的对象模型要求的项目来说，相当完美。 一般系统性能的瓶颈都在数据库上。所以这一点是iBatis非常重要的一个优势，可以进行细粒度的优化。

ibatis 比较起hibernate更垃圾，但为什么还会有这么多人用

各有长短, 谈不上谁比谁垃圾. 现在主流不都是spring-data-jpa  + mybatis么.

mybatis的sql语句放在xml中排版更好看, 然后mybatis的动态传参数也是非常方便的.

对性能没有严苛的要求用hibernate就好了.

动态组织sql这方面mybatis处理起来很方便的, 比如

用hibernate难免里写一堆判断.

不知道楼主所说XML重新生成是什么意思, 这个应该是IDE处理好的吧?

其实完全可以结合起来用.

hibernate有没有实现接口

某个超类或实现Hibernate 的某个接口。因为Hibernate 是面向对象的程序设计语
言和关系数据库之间的桥梁，所以Hibernate 允许程序开发者采用面向对象的方式
来操作关系数据库。 补充： Hibernate 概述
Hibernate 是目前最流行的ORM 框架，其采用非常优雅的方式将SQL 操作完全包装
成对象化的操作。其作者Gavin King 在持久层设计上极富经验，采用非常少的代码实现
了整个框架，同时完全开放源代码，即使偶尔遇到无法理解的情况，也可以参照源代码
来理解其在持久层上灵巧而智能的设计。
目前Hibernate 在国内的开发人员相当多， Hibernate 的文档也非常丰富，这些都为
学习Hiberante 铺平了道路，因而Hibernate 的学习相对简单一些。下面通过对比来了解
Hibernate 和传统JDBC 操作数据库持久层之间的差异。
Hibernate 的起源
当前的软件开发语言已经全面转向面向对象，而数据库系统仍停留在关系数据库阶
段。面对复杂的企业环境，同时使用面向对象语言和关系数据库是相当麻烦的，不但中
间的过渡难以理解，而且其开发周期也相当长。
Hibernate 是一个面向Java 环境的对象/关系数据库映射工具。对象/关系数据库映射194久化E( Object/Relational Mapping) 表示一种技术，用来把对象模型表示的对象映射到基于SQL
的关系模型数据结构中去。
Hibernate 的目标是:释放开发者通常的数据持久化相关的编程任务的95% 。对于以
数据为中心的程序而言，往往在数据库中使用存储过程来实现商业逻辑，Hibernate 可能
不是最好的解决方案。但对于那些基于Java 的中间件应用中，设计采用面向对象的业务
据库厂商的SQL 代码，并且把结果集由表格式的形式转换成值对象的形式。
Hibernate 不仅管理Java 类到数据库表的映射(包括Java 数据类型到SQL 数据类型
的映射) ，还提供数据查询和获取数据的方法，可以大幅度地减少在开发时人工使用SQL

为什么要学习Hibernate

在我做过的很多项目的过程中，我一直有一个悬而未决的问题在困扰我，那就是持久层的开发。持久层的开发一般来说要么用CMP，要么用JDBC＋DAO。 CMP就不用说了，它对我来说是一种失败的实践，而JDBC+DAO也存在很多的困难，我很难做到把关系表记录完整的映射到持久对象的关系上来，这主要体现在多表的关系无法直接映射到对持久对象的映射上来，可能是一个表映射多个持久对象，有可能是多个表映射一个持久对象，更有可能的是表的某些字段映射到一个持久对象，但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了，也不能直接按照对象的方式来对持久对象（PO）编程，因为存在1：N关系的持久对象的查询其实就是1+n次对数据库的SQL，我曾经有一次失败的持久层设计，结果是某个关联很多其它持久对象的PO一查询就是5n＋1次 sql，速度慢的不得了，最后不得不整个修改底层设计，最后等于是完全抛弃了对象设计，完全是按照表字段进行操作。 但是这样做非常难受，因为系统的设计是从需求设计，系统设计这样自顶而下的，结果都到了详细设计阶段了，被持久层映射问题限制，不得不自底向上修改设计方案，又回到了按照过程进行编程的老路上来，非常的糟糕。 我对这个问题思考了很久，最后终于意识到这其实是一个很经典的问题：对象和关系的映射问题。实际上自从OOP编程流行以后，就存在这个难题了，所以才有人提出关系数据库进行重新设计，改用对象数据库，但实际上关系数据库并没有被淘汰，于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种 ORM产品。 我最早想到的ORM就是JDO，于是我下载了两个JDO产品，准备认真的学习一下，但是研究了一段时间之后，我发现我对JDO非常的失望，原因如下： 1、 JDO没有一个好的开源免费实现，好的产品都是商业产品，并且在国内没有销售和技术支持。这就造成了JDO只有学习之用，不能把它用在实际项目中，否则的话，你把软件卖给客户的时候，还要告诉他，你还要另外去买一个国外的软件产品，并且在国内没有技术支持，出了持久层的问题，我们也解决不了，请你自己打国际长途去解决问题，你认为客户能答应吗？ 2、JDO不是一个轻量级封装，它试图建立一个完整的持久层框架，但是还很不完善，造成了JDO 感觉比较笨重，很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担，而且封装的太多会造成一个严重的问题就是一旦出现报错信息，调试起来非常困难，你很难准确的定位错误究竟出在哪里，封装的越轻，问题越容易定位，越容易解决，封装的越重，问题越复杂，越找不到原因，CMP就是一个很好的例子，出了错误，调试起来非常困难和麻烦。 3、JDO的标准很不完善，存在重大缺陷。最主要的问题体现在PO不能脱离PM（相当于 Hibernate的Session）而存在，这是个非常严重的问题，会造成编程的时候进行大量VO的拷贝操作，烦琐极了；另外一个重大缺陷是静态的 POJO的Enhancer，不能运行期动态Enhance，无法进行增量编译和调试，编程和调试起来非常烦琐，每次都要手共运行一个工具对POJO进行 Enhance；此外还有一些缺陷，例如JDOQL不完善，映射关系的表达不够强大等等。 4、JDO产品的分裂。这个问题也比较严重，由于JDO1.0标准的缺陷，而JDO2.0标准还遥遥无期，而各个JDO厂商为了能够在竞争中脱颖而出，那么除了在易操作性和性能上的提高之外，想要吸引客户，就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台，每个厂商都会有自己独到的解决方案来解决标准的缺陷，然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度？我可以简单举个例子：你写好的POJO，用一种JDO的Enhancer进行Enhance过以后得到的 PO，在另一个JDO产品上跑不起来。这很像当年Unix的分裂，结果就是二进制代码级的不兼容，而只能在C源代码级兼容。现在的JDO也有这样的趋势，就像App Server的差别一样，一个在Weblogic上开发好的EJB，移植到Websphere，你一定需要重新进行配置。 我心目中的ORM最好有如下的特点： 1、开源和免费的License，我可以在需要的时候研究源代码，改写源代码，进行功能的定制。 2、轻量级封装，避免引入过多复杂的问题，调试容易，也减轻程序员的负担。 3、具有可扩展性，API开放，当本身功能不够用的时候，可以自己遍码进行扩展。 4、开发者活跃，产品有稳定的发展保障。 抛弃了JDO以后，我根据上面的原则，先后排除了TopLink，CocoBase，Castor等，最后选择了Apache OJB和Hibernate。 OJB的排除很容易做出，一是因为它的文档太简单，太少；二是因为OJB计划下一个版本全面支持JDO，它的API会有重大变动，所以现阶段学习OJB是个错误，等它的API稳定了以后再学习不迟。 Hibernate的发现是很偶然的事情，只是在别人提到JDO的产品中，附带提了提而已，但当我开始研究Hibernate之后，我发现终于找到了我梦寐以求的ORM了。 Hibernate 完全符合我上面提到的标准之外，也解决掉了JDO的所有缺陷，而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方，它不仅仅是 Hibernate的功能介绍那么简单，它实际上是一个持久层设计的最佳实践的经验总结，文档里面的例子，文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是，不单单把Hibernate掌握住了，而且对持久层的设计的经验都长了一大块，以前可从来没有觉得持久层的设计还有那么多的学问，也由此感觉到Gavin绝对是一个大牛人。 当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少，而且写的非常简洁，我总觉得挺奇怪的，这么少的源代码能够实现这么多的功能，是个奇迹。 Hibernate的源代码树分的很清楚简单，源代码很易读，我一旦碰到文档中没有讲到的问题，或者文档中提到但是我搞不清楚的地方，我就去源代码中找，所有的问题都豁然开朗，而且让我对Hibernate的运行原理和细节搞的特别清楚，好像Hibernate就像自己写的代码一样，很清楚的知道，怎么写程序可以让Hibernate运行效率最高，最省内存，程序出了错误，很清楚的知道是什么地方的问题，怎么解决。

直接使用 hibernate 的人多， 还是用hibernate JPA实现的人多两者性能上、功能上有多大区别么

目前应该还是hibernate的应用更广一些，不过我个人还是更看好JPA。
首先不考虑JPA是Sun推荐的Java ee标准，关键在于jpa实体完全可以兼容Hibernate，
也就是说你按jpa标准来开发实体，那么这些实体不仅可以在jpa中使用，他可以任何遵守JPA规范
的ORM框架（包括Hibernate）中使用。
而且连与Hibernate同属于JBoss的jBPM据说也打算使用JPA来作为持久层解决方案。
这就可见JPA的魅力了。

为什么很多人不愿意用hibernate了

1、首先说一点，对于大部分人来讲框架上的选择就看周围人用的多不多，而周围人对于一个框架的选择，很重要的一点是看这个框架是否是上手快。

2、MyBatis和Hibernate相比各有各的优势，一个初学框架的程序员，宁愿会选一个简单易上手的框架开始选择，MyBatis就是很好的选择，Hibernate框架是一个集成度很高的框架，假如你在用hibernate，基本上业务层后端大部分的核心都是在用hibernate做的实现，spring框架的jpa实现实际上也是建立在hibernate对于jpa的实现的基础上的再封装，对于一个大型工程，hibernate的去SQL化也是可以提高你的开发效率的，当然，我承认hibernate的门槛确实对于初学框架的程序员，但我确信hibernate是java程序员值得去深入了解的一个开源框架。
3、我个人而言，还是比较喜欢hibernate框架的，毕竟对于SQL语句封装的够彻底（写SQL老是拼写出错- -），而且具有良好的二次封装的基因，加上spring boot（cloud）良好集成，有什么理由不用呢？

做网站用hibernate的利与弊

Hibernate的优缺点：
优点：1、程序更加面向对象；
2、提高了生产率；
3、方便移植（修改配置文件）；
4、无侵入性。
缺点：
1、效率比JDBC略差；
2、不适合批量操作。

Hibernate有四种查询方案：
1、get,load方法，根据id查找对象
2、HQL--hibernate query language（查询对象：Query)
3、Criteria--标准查询语言（查询对象：Criteria，查询条件：Criterion）
4、通过sql来查（查询对象：SQLQuery）

Hibernate中，主外键关系由外键来维护。

Hibernate中，默认的全局配置文件在src目录下为：hibernate.cfg.xml，如更改用SessionFactory sf=new SessionFactory().configure(“*/*.xml“).buildSessionFactory();指定

inverse=“true“表示此表不维护表之间的关系，由另外的表维护。

主键生成策略：
《genarator》--increment,identity,sequence,hilo,native,uuid,foreign，assigned，seqhilo，uuid.hex，uuid.string。

identity:由底层数据库生成标识符。identity是由数据库自己生成的，但这个主键必须设置为自增长，前提条件是低层数据库支持自动增长字段类型

increment:由hibernate管理主键，自动以递增的方式生成标识符，每次增量为1。其在每次插入前取得一个当前最大的id+1作为主键，该主键必须为Integer类型

“assigned”
主键由外部程序负责生成，在 save() 之前指定一个。

“hilo”
通过hi/lo 算法实现的主键生成机制，需要额外的数据库表或字段提供高位值来源

“seqhilo”
与hilo 类似，通过hi/lo 算法实现的主键生成机制，需要数据库中的 Sequence，适用于支持 Sequence 的数据库，如Oracle。

“increment”
主键按数值顺序递增。此方式的实现机制为在当前应用实例中维持一个变量，以保存着当前的最大值，之后每次需要生成主键的时候将此值加1作为主键。这种方式可能产生的问题是：不能在集群下使用。

“identity”
采用数据库提供的主键生成机制。如DB2、SQL Server、MySQL 中的主键生成机制。

“sequence”
采用数据库提供的 sequence 机制生成主键。如 Oralce 中的Sequence。

“native”
由 Hibernate 根据使用的数据库自行判断采用 identity、hilo、sequence 其中一种作为主键生成方式。

“uuid.hex”
由 Hibernate 基于128 位 UUID 算法 生成16 进制数值（编码后以长度32 的字符串表示）作为主键。

“uuid.string”
与uuid.hex 类似，只是生成的主键未进行编码（长度16），不能应用在 PostgreSQL 数据库中。

“foreign”
使用另外一个相关联的对象的标识符作为主键。