hibernate过时了吗,为什么很多人不愿意用hibernate了

hibernate过时了吗,为什么很多人不愿意用hibernate了详细介绍

本文目录一览： Hibernate已经落伍了吗？

　　在Java世界 Hibernate是最引人关注的一个话题 从Gavin King加入EJB EG 负责制订EJB 的持久层规范 到Gavin King非正式退出JDO EG 并且充满个人情绪的攻击JDO 规范 到《Hibernate in Action》的发行 再到Hibernate Alpha的发布 最后再到最近JBoss PR的发布（使用Hibernate 实现Entity Bean） 可以说这其中的每一步都引起业界的侧目
　　Hibernate在不到 年的时间里 从一个不起眼的开源软件发展到今天令业界瞩目的主流O/R Mapping框架 Gavin King从一个开源软件的作者成为业界举足轻重的人物 这多少有些传奇的色彩 毕竟 单纯从技术成就而言 Hibernate不算是最有成就的Java开源框架软件 到目前为止也不是一个完美无缺的软件 从个人技术水平而言 Gavin King也不算绝顶高手
　　在当前的Java持久层框架中 最流行的O/R Mappin *** 品分别是Hibernate JDO和TopLink
　　自从去年Gavin King加入JBoss之后 Hibernate已经由一个民间的开源软件走上了兼容EJB EntityBean的道路 然而更加令人侧目的是 Gavin King在EJB EG中充当了一个非常重要的角色 只要对比一下EJB 的EntityBean和Hibernate 真相就会大白 虽然API接口不同 但是 EntityBean的设计理念完全来自于Hibernate
　　虽然EJB 的EntityBean在相当程度上来源于Hibernate 但是毕竟是不同的API接口 因此Hibernate和EJB EntityBean究竟是怎样的一种关系 是很多人心中的疑问

　　 年四月份JBoss的Ben Wang访华期间 我曾经向Ben请教Hibernate的未来发展 他回答说 Hibernate未来将仍旧以独立的软件产品存在和发展 既可以 outside EJB container使用 同时Hibernate也将做为JBoss EntityBean Implementation 又可以inside EJB container使用 然而如何既inside 又outside 终究缺乏一个感性的认识
　　 月 日JBoss发布的 EJB PR揭开了答案 从Sourcefe的CVS服务器上面checkout出来源代码看一下 我们可以发现 Gavin King对Hibernate 进行了简单的封装 将EJB EntityBean API调用转换为内部Hibernate 自己的API 从而实现EJB EntityBean的兼容
　　EJB 不承诺脱离容器调用 如果你想享用EJB 则必须运行在某个EJB Vendor提供的容器内 例如你使用JBoss提供的容器 那么你调用的是EntityBean API 这些调用请求会被转换为Hibernate API的调用请求 这意味着Hibernate实际上提供了两套API 一套是Hibernate原生API 另一套是兼容EJB EntityBean API 对于那些需要分布式调用支持 需要EJB容器的开发人员来说 他们选择后一套API 对于不需要EJB容器的开发人员来说 他们选择前一套 API 这就是Hibernate既定的发展策略
　　今年夏天投票通过的JDO 标准从某种程度而言 并不逊色于 Hibernate当前的版本 有些功能甚至比Hibernate还要好 例如 JDO支持对类属性的lazy loading 而Hibernate要到 才支持 当前Hibernate仅仅支持类的lazy loading 实际上在去年 就已经有很多用户不断提出对类属性的lazy loading的需求 然而Gavin King当时一直不认为这个需求有添加的必要性 再例如被Gavin King形容为 可憎的 JDOQL 实际上是类SQL查询语言和对象条件查询的混合体 从功能上来说 不如HQL强大 但是比Hibernate自己的条件查询强
　　不知道究竟出于什么原因 Gavin King对JDO似乎一直怀有由衷的厌恶 月 他在Hibernate的blog上面对JDO进行了毫不留情的批判 列举了JDO的种种缺点来解释为什么EJB 持久层规范没有把JDO考虑进去 然而事实上他的批判充满了对JDO的误解和偏见 例如Gavin King憎恨JDOQL丝毫没有什么特别的理由 只因为JDOQL不是一个纯粹的查询语言 而是一个混合体 这多少让人对Gavin King的风度感到遗憾 在被Solarmetric的Abe White反驳之后 同样没有风度的说 我可没有时间做这种无谓的争论 事实上每个人都认为他自己的技术是最好的……我是错了 JDO那伙人也错了 每个人都会犯错误…… （所以说人无完人！）
　　JDO 规范的出台事实上构成了对Hibernate 乃至基于 Hibernate理念的EJB EntityBean的严重威胁 JDO 规范在功能上的严重缺失导致了JDO无力面对Hibernate和TopLink的竞争 然而功能基本完备的JDO 挟众多JDO Vendor商业支持的合力 同时JDO规范可以避免产品锁定在某个Vendor的优势 已经将竞争的天平拉直
　　
　　然而JDO 和EJB 两大商业主流标准的分裂 是大部分人 甚至包括厂商所不希望看到的 于是最终EJB 的Lead Linda DeMichiel和JDO 的Lead Craig Russell联名发表公开信 宣布了一个合并EJB 和JDO 持久层规范的计划 新的持久层规范将以JSR （EJB ）的持久层规范为基础 融合JDO 的部分特性 新的持久层规范将进入J EE 之中 独立于EJB存在 既可以inside J EE容器来使用 也可以脱离J EE容器 独立的运行
　　这个新的持久层框架可以说完全是一个政治的产物 EJB Vendors出于自身利益反对JDO 使得JDO没有办法成为J EE的一部分 然而标准的分裂也是大部分人更加不希望看到的 于是最终JDO成了政治斗争的牺牲品 从表面上来看 JDO和EJB EntityBean都将被新的持久层框架取代 似乎JDO并没有吃亏 但实际上JDO 标准已经成熟 部分JDO领导厂商的产品已经蓄始待发 而 EJB EntityBean还处于Early Draft 等待产品诞生至少也是一年之后的事情了 另外值得耐人寻味的是 新的持久层框架将基于当前EJB EntityBean 再结合JDO 的规范 并且将处于EJB EG的控制之下 再加入一些JDO EG的成员 因此可以看出来新的持久层框架无疑还是以EJB EG为主导进行制定的
　　从长远来看 EJB 和JDO 的政治斗争对双方都有好处 长期分裂带来的后果对双方的发展都不利 然而从短期来看 JDO 确实是在这场政治斗争中败下阵来 最直接的体现就是 已经有一些JDO的用户对JDO的前景产生了动摇和迷茫 不少的JDO爱好者更是直言JDO将死
　　TopLink是一个老牌的 O/R Mapping软件了 自从被Oracle收购之后 又增加了对Oracle数据库的良好支持 和对Oracle AS EntityBean的支持 Oracle提供了TopLink的图形设计环境 可以使得设计好的TopLink域模型既可以被单独用在TopLink 中 也可以被用在EJB CMP中 因此看来TopLink也走了一条和Hibernate同样策略的路
　　TopLink的问题在于相比Hibernate的开源和免费的优势来说 TopLink既不开源 售价又不菲上 本来商业软件TopLink应该在技术支持和商业宣传策略上拥有足够的优势 然而Oracle公司毕竟是一个以数据库为核心产品的公司 其他的一切产品都是为了数据库销售业绩而服务的 在Oracle产品线中处于一个从属地位的TopLink 由于先天不足 只能眼睁睁看着Hibernate的日益壮大而无所作为 因此 TopLink更多的被局限在购买了Oracle数据库 并且绑定Oracle数据库的用户群体中
　　J EE 的新持久层规范将毫无悬念的成为未来持久层框架的主流API 无论是Hibernate JDO 还是TopLink终将兼容这个主流商业API 在当前的这三种持久层API当中 Hibernate无疑是最有前途的 这是因为 新的持久层规范将基于EJB EntityBean规范 这意味着仍将以Hibernate的设计理念为基础
　　 JBoss对EJB 规范跟随的步伐非常紧密 在规范制定过程中就不断的发布参考实现产品 因此可以对对EJB 规范产生比较大的影响力
　　综上所述 我们有理由对Hibernate的前途抱有强烈的信心
　　最后的一个疑问是 既然J EE 的新持久层框架可以脱离J EE容器运行 那么大家不全部都去用Hibernate的后一套兼容API 而完全放弃Hibernate的原生API了吗？那么是否意味着Hibernate做为一个独立产品的使命彻底终结呢？
　　对于这个问题我的看法是 J EE 的持久层规范要综合各个EJB Vendor JDO Vendor的意见 要平衡他们之间的利益得失 那么这样一个瞻前顾后的规范必然无法覆盖所有应用场合的全面需要 这不像Hibernate的原生API 可以随时根据开发人员的要求增加功能那么灵活 因此我预计Hibernate的原生API以其更加强大的功能仍然会吸引一大批人直接使用原生API 而不是兼容J EE规范的API
lishixinzhi/Article/program/Java/ky/201311/28932

NHibernate已经足够了吗？

并且在博客园开了一个专栏写了一系列的文章来介绍如何使用它。到2005年后半年的时候，国内类似的代码生成工具已经开始“泛滥”了，O/RM一下子流行起来。在2005年底，我开始关注NHibernate，并逐渐转移到NHibernate上面来，对XCodeFactory的依赖也越来越小了。毕竟，NHibernate是如此得强大，以至于我不再需要XCodeFactory。
但是，对于经常要编写数据库访问代码的.NET开发人员而言，拥有NHibernate就已经足够了吗？我认为是不够的。NHibernate在基于对象方面做得非常好，这也是它初始的目标，它非常出色地实现了这个目标。但是在O/RM之外了？比如，我们需要进行批量的更新、删除等，使用NHibernate进行类似的操作不仅繁琐而且效率低下。当然，这些内容不是NHibernate的职责，NHibernate也不用关心这些O/RM之外的东西。但是，我们也许都知道了，NHibernate需要另外一个工具来作为有力的补充，这个补充主要基于关系、而不是对象来操作数据库中的数据。
有人选择了EnterpriseLibrary中的数据访问Block作为O/RM之外的补充，这很不错。而DataRabbit是另外一个选择。
相信来我blog的朋友都一定知道ESFramework，ESFramework源于EnterpriseServerBase类库的Network命名空间，而DataRabbit来源于EnterpriseServerBase类库的DataAccess命名空间，EnterpriseServerBase.DataAccess也是XCodeFactory核心库。DataRabbit中包含多个基于关系的数据访问接口，并且内置了对SqlServer、Oracle、Ole的支持，如果要支持其它类型的数据库，只需实现相应的接口即可，并且可以插件的形式提供。
（1）简化通常的数据访问，体现在IADOBase接口，IADOBase接口和以下所有接口均独立于数据库类型。
（2）数据分页 IPagerManager
（3）事务 Transaction
（4）分布式事务 Distributed
（5）操作数据大纲（DataSchema） IDataSchemaOperator ，比如获取某个表的大纲结构（Column信息、主键信息、外键信息），依据大纲在指定的数据库中创建表
（6）数据库适配器插件 IADOBaseAddin
（7）简单数据迁移 SimpleDataTransfer
这些接口将在后面的系列文章中逐一介绍。下面也看一个分页的例子，来点感性的认识。

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

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

不是说struts spring hibernate都过时了吗，为什么上课还教

其实SpringMVC也快过时了，但你不妨按照顺序都学习一下，有很大的好处。
① Servlet/JSP
② Struts2/Hibernate/Spring
③ SpringMVC/MyBatis/Spring
④ React/Vue/Angular+Restful Api
这些是基础，，，，

为什么很多人不愿意用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）良好集成，有什么理由不用呢？

Hibernate5.2.9里面 Query query=session.createQuery(); 显示Query过期，那更新一个参数用什么语句呢

没有hql语句呢
~~~~~~~~~~~
在下载的Hibernate压缩包中有详细的用户指南，最新的使用可以查看用户指南
org.hibernate包下的Query接口在hibernate5中已过时，用org.hibernate.query包下的Query接口替代--其实这接口也有好多方法过时，不过这接口本身还能用！更新不是用executeUpdate()吗？Hibernate中的Query接口是继承了javax.persistence下的Query--更准确地说应该是javax.persistence.Query这个接口的子接口TypedQuery。
查下文档就清楚了。

javaee混乱概念hibernate+spring+struts和EJB和mvc模式区别。现在常用的技术是哪些呢

mvc是模式，在架构层面的概念，ssh是个框架，里面也是mvc的模式，EJB是组件重量级的。这些看看技术介绍
亲，先给你解释一下这些东西都是什么。
mvc是一种软件设计模式它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。这是我们进行开发时要遵循的规则。
既然要遵循这个规则，那么我们怎么做才能遵循这个规则呢？这就是struts要做的了。struts是一个实现了mvc的框架，我们按照他的配置，调用他的接口来进行编程就可以实现mvc模式。
hibernate是一种持久层的框架，他其实是jdbc的一种轻量级封装，它的作用就是讲面向对象世界的对象通过面向对象的方式保存到关系型数据库中。例如，以前用jdbc编写程序保存一个学生信息，我们需要写一个insert语句，打开连接执行这个语句。但是利用hibernate，只要我们做了合理的配置，直接调用save方法就行了。
spring是一个很优秀的框架，它有自己的mvc实现，更重要的是它的依赖注入和面向切面编程功能有简单易用但有极其强大的功能。现在不少开发平台都封装了spring。
EJB是为了解决复杂问题而设计的，如分布式对象和远程事务的问题。但是很多企业级项目根本没有这么复杂，却承担了EJB的这种编写多个Java文件和部署文件，运行中量级容器的负担。只要用了EJB，不管系统要解决的问题是否复杂，甚至一个简单的系统，其复杂程度都会很高。使用Spring，系统的复杂程度是和要解决的问题的复杂程度成正比的。
怎么说呢，你说的几种技术都是很常用的，只是各自有各自的用途。
MVC是一种思想，不会过时，要一直存在这种意识。现在spring最火，用到的也最多。hibernate和struts在其各自的领域都是很牛的，但是不是每个项目都会用到。比如hibernate可以被ibatis代替，也有很多项目都直接使用原始的jdbc+sql。也有很多项目自己实现mvc框架，不选择使用struts。ejb现在有点儿没落了，但是也还有他自己的强势。
希望对你有帮助！

目前hibernate和mybatis哪个用的多

大一点的项目用hibernate，小一点的项目用mybatis，不过我用的话基本都是用的hibernate，但是我不会用到关联关系的东西，因为使用关联关系的话hibernate访问会影响效率
使用Hibernate进行编程有以下好处：
1，消除了代码的映射规则，它全部分离到了xml或者注解里面去配置。
2，无需在管理数据库连接，它也配置到xml里面了。
3，一个会话中不需要操作多个对象，只需要操作Session对象。
4，关闭资源只需要关闭一个Session便可。
这就是Hibernate的优势，在配置了映射文件和数据库连接文件后，Hibernate就可以通过Session操作，非常容易，消除了jdbc带来的大量代码，大大提高了编程的简易性和可读性。Hibernate还提供了级联，缓存，映射，一对多等功能。Hibernate是全表映射，通过HQL去操作pojo进而操作数据库的数据。
Hibernate的缺点：
1，全表映射带来的不便，比如更新时需要发送所有的字段。
2，无法根据不同的条件组装不同的SQL。
3，对多表关联和复杂的sql查询支持较差，需要自己写sql，返回后，需要自己将数据封装为pojo。
4，不能有效的支持存储过程。
5，虽然有HQL，但是性能较差，大型互联网系统往往需要优化sql，而hibernate做不到。
Mybatis：
为了解决Hibernate的不足，Mybatis出现了，Mybatis是半自动的框架。之所以称它为半自动，是因为它需要手工匹配提供POJO，sql和映射关系，而全表映射的Hibernate只需要提供pojo和映射关系即可。
Mybatis需要提供的映射文件包含了一下三个部分：sql，映射规则，pojo。在Mybatis里面你需要自己编写sql，虽然比Hibernate配置多，但是Mybatis可以配置动态sql，解决了hibernate表名根据时间变化，不同条件下列不一样的问题，同时你也可以对sql进行优化，通过配置决定你的sql映射规则，也能支持存储过程，所以对于一些复杂和需要优化性能的sql查询它就更加方便。Mybatis几乎可以做到jdbc所有能做到的事情。
什么时候使用Hibernate，Mybatis
Hibernate作为留下的Java orm框架，它确实编程简易，需要我们提供映射的规则，完全可以通过IDE生成，同时无需编写sql确实开发效率优于Mybatis。此外Hibernate还提供了缓存，日志，级联等强大的功能，但是Hibernate的缺陷也是十分明显，多表关联复杂sql，数据系统权限限制，根据条件变化的sql，存储过程等场景使用Hibernate十分不方便，而性能又难以通过sql优化，所以注定了Hibernate只适用于在场景不太复杂，要求性能不太苛刻的时候使用。
如果你需要一个灵活的，可以动态生成映射关系的框架，那么Mybatis确实是一个最好的选择。它几乎可以替代jdbc，拥有动态列，动态表名，存储过程支持，同时提供了简易的缓存，日志，级联。但是它的缺陷是需要你提供映射规则和sql，所以开发工作量比hibernate要大些。

学习Hibernate提示Entity过时，请问新的做法是什么

@Entity说明这个class是实体类，并且使用默认的orm规则，即class名即数据库表中表名，class字段名即表中的字段名
如果想改变这种默认的orm规则，就要使用@Table来改变class名与数据库中表名的映射规则，@Column来改变class中字段名与db中表的字段名的映射规则