深度吐槽hibernate
深度吐槽hibernate
闲大赋 发表于2年前
深度吐槽hibernate
  • 发表于 2年前
  • 阅读 4864
  • 收藏 85
  • 点赞 8
  • 评论 56

标题:腾讯云 新注册用户域名抢购1元起>>>   

摘要: hibernate作为一个知名ORMapping 工具,流行了10余年,给程序员带来了欢乐,也带来了痛苦。本文从4个方面来吐槽Hibernate,以此提醒负责DAO技术选择架构师,OR Mapping可能并不是一个项目好的选择。

 

   hibernate 我很久都没有用了,最后一次用应该是3年前的一个企业项目,决定采用hibernate的并不是我,是我领导,我只是开发者。我所受的罪领导并不知道。正 如我的每个hibernate项目那样,每次我都是用的提心吊胆。尽管我从ejb1.1到hiberate,然后再到jpa都经历过,这种一脉相承的技术 我了解和应用了有14年,但我还是不敢声称精通OR Mapping,尤其是最近hibernate版本又都了些新概念和新Annotation,让我还觉得我是个hibernate新手:OR Mapping 也许就是个DAO错误的方向。


让我来吐槽一下hibernate这种DAO工具,并提一下我认为完美的DAO工具。

槽点一 容器设计的败笔。 系统的核心是模型,也就是JavaBean,使用hiberante的项目,JavaBean被持久化容器劫持这是第一个槽点。尽管对模型操作,在容器的 帮助下,能很快映射到数据库操作,然而,现在越多越多的DAO框架都避免设计容器,就算是JPA规范,也只声称了是个API,而不再提持久化容器了,因为 持久化容器已经不得人心了. 以下是使用hibernate经常出现的问题(但不限于下面几个)
1 容器内,对模型的操作我不一定得映射到数据库里,可容器会强制
2 对象在容器内,一切操作都很顺利,但出了容器,会有各种hibernate异常。须知应用并不只有hibernate。
3 修改一个对象的属性,必须先从数据库load进来,成为容器管理对象,才能修改

槽点二之hierbnate能提高生产力? 我早期接触hb,并没有被所谓的容器托管Bean所吸引(上面已经说了,实际上这是个高级陷阱),我只觉得以后添加,修改都只需要调用一下HB的api就 可以了,就算是查询,也貌似很方便,有load的方法。现在看来,这些功能,几乎所有的dao框架,所有公司自己的dao工具都有,我在2002年就做过 最早的dao工具,并能自动生成dao,javabean.现在,我在beetl基础上,做了更好的beetlsql,也完全具备这种入门级功能。 吐槽hibenate并不能提高生产力,是因为其他功能提供的太容易用错和导致效率不高了,以下是hibernate效率不高的几个方面(但不限于以下俩个)
1 不可控的生成sql,每个用过hibernate的人都见只有一次api调用,可能是one2many,也可能是lazylaod,但控制台满屏的输出 sql者情况,这导致性能下降,你可以说这是开发人员不精通导致的,可是,HB为什么要提供这种手段让开人员走到这一步,好的工具应该为程序员提供便利, 阻止程序员犯错。
2 难以调试的HQL。如果你需要得到数据库专家支持,数据库人员会拒绝你给他的HQL,他需要的是SQL,数据库也需要的是SQL。所幸我项目中没有人打算 给DBA培训HQL语句(这太疯狂了,DBA估计会暴动),HQL在我看来就是一个很鸡肋的功能。如果纯粹是为了跨数据库平台,不同DAO框架都有不同方 案,比如beetlsql就共用的sql语句放一个地方,数据库特定sql语句放到指定地方.常规的翻页,序列等特性,通过方言实现类就解决了。

槽点三:annotation表达力不足, 以fetch来说,我有的业务需要eger加载,有的业务需要lazy加载,hibernate显然做不到,唯一的解决方法就是加入更多的新 annotation来表达,如果还不做到,就让annotation具备脚本或者sql功能。可问题来了,这样的极限方式不就是我们属性的程序语 言+sql 方式吗。 hiberante现在是5.0也许到了25.0版本后,他可能真的是一门语言+sql的工具了,但这样有什么意义呢。 我认为annotation,最多只能描述表映射就可以了。很多其他框架就是这么做的。如下是一些经常的槽点(但不限于以下三个槽点):
1 fetch 模式 根据业务来的,但annotation只能一种,我选用哪种都不合适
2 我的数据库之间表关系并不严格(这常见),导致hibernate 都启动不了
3 我想敏捷开发,把已经确定的做出来,但hibernate要求我有完整的模型,否则,都启动不起来

大部分其他dao框架都不会出现上面的问题。

槽点四:程序中的SQL是个重要资产,需要维护,但hibernate并没有去做。HB 最早是只有xml配置文件,作者认为只要通过配置就能完成所有dao操作,但是后来发现不行,就又搞了一个HQL,结果发现HQL跟SQL完全不能比,最 后支持Native SQL. 就算这样的演进,但HB作者仍然没有意识到SQL才是DAO的核心, 需要重点维护。 这也是Mybatis,Beetlsql框架能让大家接受并喜爱的原因。
通过Java拼接hql或者sql问题不大,无非是把数据库调试好的的几十行sql拆开拼接就好了。但这样开发效率不高,更重要的是,维护效率低,一旦业 务有改动,sql机会不得不重新在java里拼接。hibernate 本来应该像sql那样提供sql拼接,但并没有,反而是mybatis,beetlsql在这方便做的很好。

越来越多的人意识到hibernte是个问题,从而转用了mybatis, jfinal,nutzdao,beetlsql 等这样的开源dao工具,我认为一个理想的dao工具,应该有如下功能是必须的:

1 好的dao工具,支持javabean模型
2 好的dao工具,在javabean基础上,不能干涉javabean模型
3 支持sql的维护,如像beetlsql 那样通过markdonw格式维护sql,或者像myabtis那样通过xml维护
4 支持跨数据库平台
5 简单的数据库操作无需用户开发,大部分dao工具都能做到这点,比如beetlsql支持新增,修改,根据模板修改,根据主键查询,根据模板查询等,至少40%的dao代码都不需要重写
6 代码生成,比如生成javabean,生成dao代码,生成查询sql语句等
8 dao工具并不能要求数据库完全符合数据库高级范式,也不要求程序完全的OO。
7 最为重要的是,dao工具必须是个工具,任由开发人员使用。
标签: hibernate beetlsql
共有 人打赏支持
闲大赋
粉丝 950
博文 83
码字总数 76635
作品 9
评论 (56)
程序猿猴
开始学的时候感觉它会给我打来快乐,结果我错了。
程序猿猴
开始学的时候感觉它会给我打来快乐,结果我错了。
闲大赋

引用来自“程序猿猴”的评论

开始学的时候感觉它会给我打来快乐,结果我错了。
我也是,痛苦更多点
肖得明
hb就一天坑。用过的都说坑。
李嘉图
hibernate总之就是不喜欢,因为效率太低了,不好优化,总之,还是要承认以SQL为中心,才能从根本解决问题.
Smile月光
mybatis愉快的解决问题
lgscofield
方言,多库适配mybatis有点无力
潘-C
图配的真是恰到好处!hb对于一些新人来说 无疑是个好东西 因为不用自已写sql 还能持久化 ,一旦接触到ibatis、beetlsql这样的开源DAO,原来能控制SQL才是真理。
冬日暖阳85
如果是面对基于数据库的应用领域,不会SQL的程序员所能控制的事情是极少的。哦,可以改下按钮上的文字大小。
小菜的粉丝
讲得很好呀,HB至今还没有精通...
-飞客-
HIBERNATE 适合 面向对象设计的系统。
显然面向对象不是万能的,适合 速度要求不高 但 业务复杂 的系统。
如果一个系统从开始设计就不是面向对象的那么用HIBERNATE只能是痛苦 + 痛苦。
wuyiw
第四点颇有同感, 当hql不能满足时在java里面拼sql字符串真是蛋疼得一比, 可读性/可维护性都很差, 后来放到xml配置里用namedQuery调用才好些.
开源中国CTO
自己写个用
闲大赋

引用来自“开源中国CTO”的评论

自己写个用
不用你自己写了,直接用beetlsql
沧海_Sea
刚学的时候感觉很好 后来发现是啥鸡巴玩意、、、
闲大赋

引用来自“沧海_Sea”的评论

刚学的时候感觉很好 后来发现是啥鸡巴玩意、、、
一直不敢生成精通HB,现在觉得根本没有必要用它
啦啦啦拉拉
罪魁祸首是SQL,如果数据本身的查询语言
闲大赋

引用来自“zonghua”的评论

罪魁祸首是SQL,如果数据本身的查询语言
sql是数据库的一部分l,你这个说法难道要改变数据库?
路小磊
HB用过的都说是大坑……唉,简单CRUD非常好,一旦涉及SQL优化和多表问题,复杂的一塌糊涂。所以我现在用自己封装的ORM框架http://hutool.mydoc.io/?t=820
徐承恩
一直在用Mybatis,现在开始支持大赋的beetlsql.大赋威武
×
闲大赋
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: