最近用到了这个,网上找了有关Hibernate,大家对它使用的意见,看到下面的文章,写的好像蛮详细,看评论的也有不同意见的,
由于自己没有用过难以判断啊,应该是易用性上不怎么,这个没什么偏见!考虑用MyBatis了,也一边研究研究Hibernate!
来源:http://www.blogjava.net/shinewang/archive/2009/01/21/245309.html
Hibernate确实功能强悍,但在易用性、性能上存在缺陷。如果团队中没有一个精通Hibernate的高手,不适合使用Hibernate。
1. 复杂的实体状态
3种实体状态的设计是种种复杂性问题的根源。在持久化状态下不需要save就自动同步到数据库既无必要又容易造成烦恼。
2. Lazy Load 与 Eager Load
Lazy Load的概念听起来不错,用起来就不那么妙了,也直接导致产生了Open Session In View这种妥协方案。此外,在domain类中定义的FetchType只针对get/load/loadAll有效,对Query是无效的,需要再次定义。
3. Open Session In View
Lazy Load引发的一个有较多副作用的解决方案。
4. 级联
级联是一个很好很OO的概念,但往往增加了复杂度。
5. 批量更新与缓存不一致
Hibernate引入了一级缓存和二级缓存,提供了性能的同时带来了缓存一致性的问题。批量更新或者其他系统对数据库的更新容易造成缓存不一致。
6. 配置繁琐
Hibernate最初只能使用xml进行配置,后来终于引入了Annotation和CoC(约定优于配置)来简化配置,但这种变革并不彻底。Hibernate默认把userName映射userName,但实际开发中,把userName映射为user_name的情况更多些。
7. HQL
HQL是一个类SQL对象查询语言,但正是因为HQL与SQL的相似性,往往容易造成混淆,同时HQL难以调试,本质创建了一种语言,增加学习成本。
8. 太多的查询方案
HQL、QBC、SQL,就不能统一点,简洁点?
9. N+1次查询
10. 性能问题
总之,Hibernate立足于作一个完整的自动化的能够适应各种环境的ORM,因此带来了100%的复杂性。但我们实际需要的只是一个简单的能够以20%时间解决80%问题的框架,具有对象-关系映射,能自动生成SQL,能够让新手尽快工作就足够了,也许ActiveRecord是一个选择。
由于自己没有用过难以判断啊,应该是易用性上不怎么,这个没什么偏见!考虑用MyBatis了,也一边研究研究Hibernate!
来源:http://www.blogjava.net/shinewang/archive/2009/01/21/245309.html
Hibernate确实功能强悍,但在易用性、性能上存在缺陷。如果团队中没有一个精通Hibernate的高手,不适合使用Hibernate。
1. 复杂的实体状态
3种实体状态的设计是种种复杂性问题的根源。在持久化状态下不需要save就自动同步到数据库既无必要又容易造成烦恼。
2. Lazy Load 与 Eager Load
Lazy Load的概念听起来不错,用起来就不那么妙了,也直接导致产生了Open Session In View这种妥协方案。此外,在domain类中定义的FetchType只针对get/load/loadAll有效,对Query是无效的,需要再次定义。
3. Open Session In View
Lazy Load引发的一个有较多副作用的解决方案。
4. 级联
级联是一个很好很OO的概念,但往往增加了复杂度。
5. 批量更新与缓存不一致
Hibernate引入了一级缓存和二级缓存,提供了性能的同时带来了缓存一致性的问题。批量更新或者其他系统对数据库的更新容易造成缓存不一致。
6. 配置繁琐
Hibernate最初只能使用xml进行配置,后来终于引入了Annotation和CoC(约定优于配置)来简化配置,但这种变革并不彻底。Hibernate默认把userName映射userName,但实际开发中,把userName映射为user_name的情况更多些。
7. HQL
HQL是一个类SQL对象查询语言,但正是因为HQL与SQL的相似性,往往容易造成混淆,同时HQL难以调试,本质创建了一种语言,增加学习成本。
8. 太多的查询方案
HQL、QBC、SQL,就不能统一点,简洁点?
9. N+1次查询
10. 性能问题
总之,Hibernate立足于作一个完整的自动化的能够适应各种环境的ORM,因此带来了100%的复杂性。但我们实际需要的只是一个简单的能够以20%时间解决80%问题的框架,具有对象-关系映射,能自动生成SQL,能够让新手尽快工作就足够了,也许ActiveRecord是一个选择。
评论
本人弄的一个快速开发平台ajf(agile java framework)
里面有轻量级的ORM组件,大家可看看,消遣娱乐下
http://hi.baidu.com/ajf8/blog/item/d8861435117ff23d5ab5f5fc.html" target="_new" rel="nofollow"> http://hi.baidu.com/ajf8/blog/item/d8861435117ff23d5ab5f5fc.html
http://hi.baidu.com/ajf8 回复 更多评论
里面有轻量级的ORM组件,大家可看看,消遣娱乐下
http://hi.baidu.com/ajf8/blog/item/d8861435117ff23d5ab5f5fc.html" target="_new" rel="nofollow"> http://hi.baidu.com/ajf8/blog/item/d8861435117ff23d5ab5f5fc.html
http://hi.baidu.com/ajf8 回复 更多评论
作者的观点十分荒谬可笑,估计高手都懒得回复你了:
1. 复杂的实体状态
持久,瞬时,托管。三个状态非常完美的表示了对象和数据库的交互(绑定了Session,就将内存和数据库连接起来了),绑定了Session,如果一个对象在数据库中没有对应的记录,而只存在于内存中,就是瞬时的;如果一个对象在数据库中有对应的记录,而且现在在内存里,就是持久的。没有绑定Session,如果一个对象在数据库里有对应的记录,而现在它在内存中,就是托管的。
请问这复杂吗?
关于自动同步问题,只要你读过一遍那个薄薄的Hibernate开发手册,就该知道这些问题啊,不看使用说明书,就使用产品,这是很多人的通病吧。
2. Lazy Load 与 Eager Load
Open Session In View本质是一次会话一个事务这种模式,你当然可以使用托管对象模式,谁说的Lazy Load直接导致了OSIV?
3. Open Session In View
同上
4. 级联
级联删除是数据库本身就有的选项,至于级联插入和修改,以及集合元素的remove都是符合语义的,我知道你的担心,怕关联对象自动插入出现问题,计算机不是掷骰子,因此这种担心是多余的。
5. 批量更新与缓存不一致
你可以修改缓存策略,不想用就不用。更何况大型的网站怎么可能不用缓存呢,即使你不在应用层加,很多大型数据库也是会带缓存的。
6. 配置繁琐
数据库和程序是怎么对应起来的,你总得在一个地方标明吧,要不系统怎么知道你是怎么对应起来的。你用JDBC就是写insert 字段 vlaues(值),将字段和值对应起来,只不过Hibernate配置换了个地方,把这种对照关系写在了配置文件里。而且写一次就OK了,你不必写update的时候,再去看看程序中的哪个变量与数据库的哪个字段要对应上。
Hibernate提供了默认的配置,是在简化你的开发啊。
7. HQL
HQL在做些简单的查询时使用可以简化你的代码,而复杂的查询就不要用了,稍微复杂点可以用QBC,实在不行了用SQL,不同的复杂程度,用不同的解决方案,Hibernate想的很周到。好比你吃粉条最好用筷子,喝汤最好用勺,啃排骨最好用手。
8. 太多的查询方案
见上一个问题
9. N+1次查询
N+1次查询和笛卡尔乘积是一个鱼和熊掌不可兼得的权衡,Hibernate提供了不同场景的不同方案。和第7个问题一个道理,你应该使用恰当的方法。
10. 性能问题
Hibernate只是帮助你生成了一些SQL语句,创建和管理了一些对象,这两个过程你不用Hibernate也会自己做,你可以把自己写的代码,跟Hibernate执行过程做个对比,通常情况下,你写的SQL,未必有Hibernate生成的好,毕竟人家是专业的SQL专家写的SQL语句。 回复 更多评论
1. 复杂的实体状态
持久,瞬时,托管。三个状态非常完美的表示了对象和数据库的交互(绑定了Session,就将内存和数据库连接起来了),绑定了Session,如果一个对象在数据库中没有对应的记录,而只存在于内存中,就是瞬时的;如果一个对象在数据库中有对应的记录,而且现在在内存里,就是持久的。没有绑定Session,如果一个对象在数据库里有对应的记录,而现在它在内存中,就是托管的。
请问这复杂吗?
关于自动同步问题,只要你读过一遍那个薄薄的Hibernate开发手册,就该知道这些问题啊,不看使用说明书,就使用产品,这是很多人的通病吧。
2. Lazy Load 与 Eager Load
Open Session In View本质是一次会话一个事务这种模式,你当然可以使用托管对象模式,谁说的Lazy Load直接导致了OSIV?
3. Open Session In View
同上
4. 级联
级联删除是数据库本身就有的选项,至于级联插入和修改,以及集合元素的remove都是符合语义的,我知道你的担心,怕关联对象自动插入出现问题,计算机不是掷骰子,因此这种担心是多余的。
5. 批量更新与缓存不一致
你可以修改缓存策略,不想用就不用。更何况大型的网站怎么可能不用缓存呢,即使你不在应用层加,很多大型数据库也是会带缓存的。
6. 配置繁琐
数据库和程序是怎么对应起来的,你总得在一个地方标明吧,要不系统怎么知道你是怎么对应起来的。你用JDBC就是写insert 字段 vlaues(值),将字段和值对应起来,只不过Hibernate配置换了个地方,把这种对照关系写在了配置文件里。而且写一次就OK了,你不必写update的时候,再去看看程序中的哪个变量与数据库的哪个字段要对应上。
Hibernate提供了默认的配置,是在简化你的开发啊。
7. HQL
HQL在做些简单的查询时使用可以简化你的代码,而复杂的查询就不要用了,稍微复杂点可以用QBC,实在不行了用SQL,不同的复杂程度,用不同的解决方案,Hibernate想的很周到。好比你吃粉条最好用筷子,喝汤最好用勺,啃排骨最好用手。
8. 太多的查询方案
见上一个问题
9. N+1次查询
N+1次查询和笛卡尔乘积是一个鱼和熊掌不可兼得的权衡,Hibernate提供了不同场景的不同方案。和第7个问题一个道理,你应该使用恰当的方法。
10. 性能问题
Hibernate只是帮助你生成了一些SQL语句,创建和管理了一些对象,这两个过程你不用Hibernate也会自己做,你可以把自己写的代码,跟Hibernate执行过程做个对比,通常情况下,你写的SQL,未必有Hibernate生成的好,毕竟人家是专业的SQL专家写的SQL语句。 回复 更多评论
@零雨其蒙
很多人没有仔细看明白我的意思就忍不住开始喷了,早不想回复这个帖子,看到你写了这么多,还是回复一下比较尊重,我写这篇文章主要基于以下的出发点:
1、我只列了问题没有写解决的方法并不代表我不会,遇到问题想办法解决,根据环境选择合适的方案,我想是作为一个合格的开发者的必要条件
2、Hibernate有过度设计的地方,这些理念可能在理论上很完美,但是实践中我已经看到多次开发人员因为没有意识到这种过渡设计隐含的风险而造成Bug
3、Hibernate存在冗余的设计,毕竟Hibernate有段历史了,历史的包袱也不是能随便抛掉的
4、如果Hibernate的开发人员重新设计一个新的ORM,我想肯定比现在的好吧 回复 更多评论
很多人没有仔细看明白我的意思就忍不住开始喷了,早不想回复这个帖子,看到你写了这么多,还是回复一下比较尊重,我写这篇文章主要基于以下的出发点:
1、我只列了问题没有写解决的方法并不代表我不会,遇到问题想办法解决,根据环境选择合适的方案,我想是作为一个合格的开发者的必要条件
2、Hibernate有过度设计的地方,这些理念可能在理论上很完美,但是实践中我已经看到多次开发人员因为没有意识到这种过渡设计隐含的风险而造成Bug
3、Hibernate存在冗余的设计,毕竟Hibernate有段历史了,历史的包袱也不是能随便抛掉的
4、如果Hibernate的开发人员重新设计一个新的ORM,我想肯定比现在的好吧 回复 更多评论
@shinewang
1 我并没有说你不会,我知道你会配置OSIV,但是你好像并不知道OSIV的来历,要不然你也不会说出是延迟加载导致了OSIV。
你也会配置Hibernate映射,但是我不知道将你的程序和数据库模式对应上除了写映射和SQL语句(或者类似物)还有什么第三种方式?既然没有,那么写映射肯定更简单,而且Hibernate提供很好的默认值,怎么会说繁琐呢。
你或许只会操作,但是并不懂得背后的原理,有些甚至都不会操作。
2 我不认为Hibernate有什么过度设计的问题,只能说明那些问题你可能没有意识到,过去我也是这样,不知道你读没读过Martin Fowler的企业应用架构模式和Gavin King的Hibernte实战以及Rod Johnson的三本书,我觉得那些在开发中我们会遇到的问题或者麻烦,Hibernate都周到的用世界级的方法帮我们解决了。
3 Hibernate3已经和Hibernate2是不同的包了,很多东西都改了,新版本只能说是日臻完善,越来越好,我是没看出来他有什么地方是妥协的。另外不知道你用没用过EJB2.1,那个东西很简单,关键是很多问题没解决啊
4 新的Hibernate那就应该是EJB3了,这个项目也是Gavin King主持的,除了标准化了基础设施,也没什么太多新的东西,毕竟ORM的理论Fowler8年前就论述清楚了,而且像Toplink这样的商业级ORM都有十年历史了 回复 更多评论
1 我并没有说你不会,我知道你会配置OSIV,但是你好像并不知道OSIV的来历,要不然你也不会说出是延迟加载导致了OSIV。
你也会配置Hibernate映射,但是我不知道将你的程序和数据库模式对应上除了写映射和SQL语句(或者类似物)还有什么第三种方式?既然没有,那么写映射肯定更简单,而且Hibernate提供很好的默认值,怎么会说繁琐呢。
你或许只会操作,但是并不懂得背后的原理,有些甚至都不会操作。
2 我不认为Hibernate有什么过度设计的问题,只能说明那些问题你可能没有意识到,过去我也是这样,不知道你读没读过Martin Fowler的企业应用架构模式和Gavin King的Hibernte实战以及Rod Johnson的三本书,我觉得那些在开发中我们会遇到的问题或者麻烦,Hibernate都周到的用世界级的方法帮我们解决了。
3 Hibernate3已经和Hibernate2是不同的包了,很多东西都改了,新版本只能说是日臻完善,越来越好,我是没看出来他有什么地方是妥协的。另外不知道你用没用过EJB2.1,那个东西很简单,关键是很多问题没解决啊
4 新的Hibernate那就应该是EJB3了,这个项目也是Gavin King主持的,除了标准化了基础设施,也没什么太多新的东西,毕竟ORM的理论Fowler8年前就论述清楚了,而且像Toplink这样的商业级ORM都有十年历史了 回复 更多评论
@零雨其蒙
1、OSIV是解决Lazy Load最简便的方法,所以我说Lazy Load导致我们选择使用OSIV,而OSIV又有副作用。
2、繁琐是相对而言的,相比Rails的ActiveRecord而言确实要麻烦些。
3、我说的Hibernate的过度设计就是自动与数据库同步,这看起来是一种智能的方式,其实是一种不良的易用性。
4、我和你意见的分歧主要在于我关注的是80%简单的应用,特别是Web应用,你关注的是20%复杂的应用,也就是真正意义上的企业级应用,正像你说的Hibernate提供的是世界级的方法,能解决开发中我们会遇到的问题或者麻烦,确实如此,我在之前就说过了Hibernate立足于作一个完整的自动化的能够适应各种环境的ORM,因此带来了复杂性。不同的领域自然会形成不同的工具需要。 回复 更多评论
1、OSIV是解决Lazy Load最简便的方法,所以我说Lazy Load导致我们选择使用OSIV,而OSIV又有副作用。
2、繁琐是相对而言的,相比Rails的ActiveRecord而言确实要麻烦些。
3、我说的Hibernate的过度设计就是自动与数据库同步,这看起来是一种智能的方式,其实是一种不良的易用性。
4、我和你意见的分歧主要在于我关注的是80%简单的应用,特别是Web应用,你关注的是20%复杂的应用,也就是真正意义上的企业级应用,正像你说的Hibernate提供的是世界级的方法,能解决开发中我们会遇到的问题或者麻烦,确实如此,我在之前就说过了Hibernate立足于作一个完整的自动化的能够适应各种环境的ORM,因此带来了复杂性。不同的领域自然会形成不同的工具需要。 回复 更多评论
@shinewang
1 对于延迟加载,OSIV使得你不必要关心事务,也没了托管的概念,是一种简化
2 ActiveRecord是怎么做的?无非就是约定优于配置+参数绑定。我真不知道还有什么第三种方式能能系统自动的就知道程序中的username和user_name是对应的,用怎么知道username和f_user_name是对应的,大家习惯都是不一样的。按照Fowler的说法,ActiveRecord是在Transaction Script和ORM中的一个折衷。
3 Hibernate的哲学是管理对象和数据状态,而不是做数据操作。你把他理解为数据操作就错了,实际上,Hibernate的操作是状态转换,底层才是JDBC的操作。因此这不是过度设计,只是一种理论的实现罢了。
4 最后这点确实是问题的关键,因为我们关注的方面不同。
如果是小应用,非要选择Java的话,持久层还是用iBatis或者用Spring的JdbcTemplate比较容易理解。但是,如果你懂Hibernate的话,小应用使用Hibernate同样非常敏捷,我们项目中的基础数据维护就是用Hibernate做基础,然后编写了一个通用的DAO(继承自泛型DAO),只要把实体的类set进去,然后就可以对这个实体进行CRUD操作了。另外Hibernate的属性与字段默认对照你是可以重写方法变成你喜欢的样子,比如让username自动去对应user_name(开源就是好~~)。
总而言之,并不是Hibernate有十大罪状,而是:
1 没有理解Hibernate是什么
2 不看说明书就使用家用电器。在这里我不说家用电器的事,那时我买了件马克华菲的衣服,洗了一次发现有点掉色,心里暗想这么贵的衣服怎么质量这么差。拿去洗衣房,洗衣房的阿姨告诉我,这种大品牌的衣服,在衣服的内兜或者底襟的地方都有洗涤说明的,我一看,才发现自己洗错了。这件事情告诉我,每件事情都有其内在客观规律,你必须要遵守的。 回复 更多评论
1 对于延迟加载,OSIV使得你不必要关心事务,也没了托管的概念,是一种简化
2 ActiveRecord是怎么做的?无非就是约定优于配置+参数绑定。我真不知道还有什么第三种方式能能系统自动的就知道程序中的username和user_name是对应的,用怎么知道username和f_user_name是对应的,大家习惯都是不一样的。按照Fowler的说法,ActiveRecord是在Transaction Script和ORM中的一个折衷。
3 Hibernate的哲学是管理对象和数据状态,而不是做数据操作。你把他理解为数据操作就错了,实际上,Hibernate的操作是状态转换,底层才是JDBC的操作。因此这不是过度设计,只是一种理论的实现罢了。
4 最后这点确实是问题的关键,因为我们关注的方面不同。
如果是小应用,非要选择Java的话,持久层还是用iBatis或者用Spring的JdbcTemplate比较容易理解。但是,如果你懂Hibernate的话,小应用使用Hibernate同样非常敏捷,我们项目中的基础数据维护就是用Hibernate做基础,然后编写了一个通用的DAO(继承自泛型DAO),只要把实体的类set进去,然后就可以对这个实体进行CRUD操作了。另外Hibernate的属性与字段默认对照你是可以重写方法变成你喜欢的样子,比如让username自动去对应user_name(开源就是好~~)。
总而言之,并不是Hibernate有十大罪状,而是:
1 没有理解Hibernate是什么
2 不看说明书就使用家用电器。在这里我不说家用电器的事,那时我买了件马克华菲的衣服,洗了一次发现有点掉色,心里暗想这么贵的衣服怎么质量这么差。拿去洗衣房,洗衣房的阿姨告诉我,这种大品牌的衣服,在衣服的内兜或者底襟的地方都有洗涤说明的,我一看,才发现自己洗错了。这件事情告诉我,每件事情都有其内在客观规律,你必须要遵守的。 回复 更多评论
@零雨其蒙
你举的这个例子很合适,问题就在于现实生活中究竟有多少人会去仔细看说明书,现在很多家电厂商提供两本说明书,一本是薄一点的快速入门指南,一本是产品的详细说明书,大多数人都是看了快速入门指南就开始使用了,你的产品应该保证用户在按照快速入门指南中描述的方法、模式、思维使用产品的基本功能不出现错误,更好的产品甚至不需要这本快速入门指南,用户可以按照从其他类似产品获得的使用经验来使用。Hibernate就像你那件大品牌的衣服,很多开发者看了一些入门的指南、图书就开始使用,然后某天出Bug了,最终“在衣服的内兜或者底襟的地方”发现是有“洗涤说明”的。你也许会觉得这是他们没有仔细看详细说明书造成的,但现实是开发者不可能放着项目不做而先花大量时间去琢磨透每个细节后才开始使用Hibernate,要真正学好Hibernate花费的时间可不是一个小数目,就算我们敢于花这笔学习时间上的投资,把手头上的项目停掉,把时间都花在学hibernate上,又能不能保证每个开发者会去仔细琢磨,我觉得最终的结果是大部分开发者自认为学会了学好了其实则不然。Hibernate的自动化很多容易给人造成一种印象,以为这是个简单的东西,其实但凡自动化的装置本身就是一个复杂的东西,如果本身设计得不到位,容易产生比较较陡的学习曲线,容易产生错误,算上学习成本和修补错误的时间后使用效率不见得就比手动设备高。 回复 更多评论
你举的这个例子很合适,问题就在于现实生活中究竟有多少人会去仔细看说明书,现在很多家电厂商提供两本说明书,一本是薄一点的快速入门指南,一本是产品的详细说明书,大多数人都是看了快速入门指南就开始使用了,你的产品应该保证用户在按照快速入门指南中描述的方法、模式、思维使用产品的基本功能不出现错误,更好的产品甚至不需要这本快速入门指南,用户可以按照从其他类似产品获得的使用经验来使用。Hibernate就像你那件大品牌的衣服,很多开发者看了一些入门的指南、图书就开始使用,然后某天出Bug了,最终“在衣服的内兜或者底襟的地方”发现是有“洗涤说明”的。你也许会觉得这是他们没有仔细看详细说明书造成的,但现实是开发者不可能放着项目不做而先花大量时间去琢磨透每个细节后才开始使用Hibernate,要真正学好Hibernate花费的时间可不是一个小数目,就算我们敢于花这笔学习时间上的投资,把手头上的项目停掉,把时间都花在学hibernate上,又能不能保证每个开发者会去仔细琢磨,我觉得最终的结果是大部分开发者自认为学会了学好了其实则不然。Hibernate的自动化很多容易给人造成一种印象,以为这是个简单的东西,其实但凡自动化的装置本身就是一个复杂的东西,如果本身设计得不到位,容易产生比较较陡的学习曲线,容易产生错误,算上学习成本和修补错误的时间后使用效率不见得就比手动设备高。 回复 更多评论
@shinewang
可能你理解的快速入门指南是Get Started(Reference的第一章,里面的确没有谈及Update),而我认为Hibernate Reference就是所说的快速入门指南了。而详细说明书则是Hibernate实战那本书。阅读一遍Reference大约只需要3天时间,因为一共才20章。
如果数据库,J2EE基础很差,而且一个项目的周期只有2个月,那就不要用Hibernate了,我发现很多人看了那个Reference时说看不懂,很多都是因为他连JDBC、事务隔离级别,数据库范式,和典型的开发模式都不知道,看不懂就是自然的了。
如果项目周期有两年,那么花1个星期把Reference里的内容都实验一遍,应该基本不会出问题的。
如果您有时间的话,可以写Hibernate的十大陷阱,我觉得更有益处~~~ 回复 更多评论
可能你理解的快速入门指南是Get Started(Reference的第一章,里面的确没有谈及Update),而我认为Hibernate Reference就是所说的快速入门指南了。而详细说明书则是Hibernate实战那本书。阅读一遍Reference大约只需要3天时间,因为一共才20章。
如果数据库,J2EE基础很差,而且一个项目的周期只有2个月,那就不要用Hibernate了,我发现很多人看了那个Reference时说看不懂,很多都是因为他连JDBC、事务隔离级别,数据库范式,和典型的开发模式都不知道,看不懂就是自然的了。
如果项目周期有两年,那么花1个星期把Reference里的内容都实验一遍,应该基本不会出问题的。
如果您有时间的话,可以写Hibernate的十大陷阱,我觉得更有益处~~~ 回复 更多评论
@shinewang
非常同意楼主的观点。
程序员都会有意识的维护自己掌握的知识体系,如果有人说自己掌握的技术有问题,那就等于说自己过去的学习是没有价值的,这是程序员盲目性的一个体现。
既然大家都在讨论Hibernate,Ejb等,那就说明大家都在做企业应用开发,但是有没有人进行过深入思考,什么叫企业应用,这个行业有什么特点。根据我的了解,没有哪个做企业应用的公司会把技术架构放在第一位,因为说穿了我们是做服务的,只有服务好了我们的客户,我们才能很好的生存。所以我们选择技术架构的第一准则就是高效易用,这样的话我们才能把更多的精力放在用户的业务上。在企业应用这个范畴,技术是为业务服务的。估计楼主的思考也是基于这样的角度吧!
回复 更多评论
非常同意楼主的观点。
程序员都会有意识的维护自己掌握的知识体系,如果有人说自己掌握的技术有问题,那就等于说自己过去的学习是没有价值的,这是程序员盲目性的一个体现。
既然大家都在讨论Hibernate,Ejb等,那就说明大家都在做企业应用开发,但是有没有人进行过深入思考,什么叫企业应用,这个行业有什么特点。根据我的了解,没有哪个做企业应用的公司会把技术架构放在第一位,因为说穿了我们是做服务的,只有服务好了我们的客户,我们才能很好的生存。所以我们选择技术架构的第一准则就是高效易用,这样的话我们才能把更多的精力放在用户的业务上。在企业应用这个范畴,技术是为业务服务的。估计楼主的思考也是基于这样的角度吧!
回复 更多评论
@热心网友
我回复一下,我并不是什么框架的拥护者 只是觉得 LZ武断判断不是很好。
1. 实体状态和缓存关联,持久化不用save,那是因为用了spring,spring又多了一层对hibernate控制的封装,不是持久化不用save,而是spring不用save,spring封装了save动作,程序人员看不见了而已,你要手动管理,你看看要不要save
2. lazy load 我反而觉得lazyload是一个非常好的东西,hibernate的本质原理是要保持数据完整性,所有操作都是在保持数据完整性的基础上才能进行操作。lazy load 把级联实体抛弃,只取一部分数据,我觉得很好啊。当然有缺点是,程序结束时并不能lazy load,也就是说 lazy load 只能在程序内,return了就全都取出来了。
3. Open Session In View 已经没多少人用了,老项目在用,新的已经不用了
4. 级联,这条就纯属扯淡 , 数据库范式本身就存在级联概念,hibernate的级联就不是只有hibernate有,用sql 不用级联的么?你的where的语句本质不是级联么
5. 批量更新与缓存不一致, 读写分离 解决这问题 ,非要 大量的读和少量的写参和在一起,缓存不一致的问题,敢问你用肉眼能判断出来是你电脑内存不够了呢,还是本身缓存有问题。 读写分离 解决。
6. 配置繁琐, 这条也是扯淡的 ,jdbc 写一大堆sql繁琐不繁琐,凡事都是平衡的,得到一些东西必定意味着你要牺牲一些东西,你得到了开发容易,那么好你只能牺牲配置繁琐。
7. HQL,这条是面相对象惹的祸,其次我个人的看法,不一定准确:如果某人开发了一个产品,大家都喜欢封装,不让别人看到,那么hibernate也是,我做好了我就封装起来,我封装的代码要比屌丝程序员写的好,如果你想研究,那请你学习hibernate的源码
8. 太都查询方案,这条也扯淡,这叫灵活,不要太多查询方案,纯吹毛求si
9. N+1次查询, 这个确实是这样的,我也比较诟病这个问题
10. 性能问题,这个其实是有争议的,有人说大型项目用hibernate不行,可是某大型网站用的是hibernate,PV量也不少,也没见down掉。性能问题确实是仁者见仁智者见智,并且性能问题是个无底洞,没有最好只有更好,所以这个问题是个公共的问题。
总结:回复者里面有个人说了,没有失败的框架设计者,只有失败的程序员。我是比较赞同的, 框架只要精通,用的好,就可以解决问题,况且,市面上有很多项目是jdbc和hibernate并用的,sql大了就用jdbc,简单的东西直接用hibernate,一棒子打死,不科学,hibernate存在的时候,好多人都没学计算机呢,等你学完计算机了,hibernate还存在着。存在即价值,根本没有标准定义一个东西适合什么,一个东西不适合什么。这些个写框架的人都是行业里的翘楚,说白了,人家智商拿出来都比正常人多半斤,你考虑的常识问题人家还没考虑到,那不白混这么多年了。总之,hibernate是一款很实用的框架,尽管有一些使用方法在满足特定需求的时候是有些冗余,but条条大路通罗马通罗马,用hibernate遇到了这个问题,最先想到的不应该是放弃使用hibernate,而是如何在使用hibernate的基础把这个问题解决了,我敢保证,你使用其他的可能会解决你当前的这个问题,但是肯定会出现其他不是按照你的思路产生的问题,到时候怎么办,把那个框架再换了,最后使用jdbc,自己又嫌写sql太麻烦,太多,那就不要写程序了,歇着不麻烦,还不累。 回复 更多评论
我回复一下,我并不是什么框架的拥护者 只是觉得 LZ武断判断不是很好。
1. 实体状态和缓存关联,持久化不用save,那是因为用了spring,spring又多了一层对hibernate控制的封装,不是持久化不用save,而是spring不用save,spring封装了save动作,程序人员看不见了而已,你要手动管理,你看看要不要save
2. lazy load 我反而觉得lazyload是一个非常好的东西,hibernate的本质原理是要保持数据完整性,所有操作都是在保持数据完整性的基础上才能进行操作。lazy load 把级联实体抛弃,只取一部分数据,我觉得很好啊。当然有缺点是,程序结束时并不能lazy load,也就是说 lazy load 只能在程序内,return了就全都取出来了。
3. Open Session In View 已经没多少人用了,老项目在用,新的已经不用了
4. 级联,这条就纯属扯淡 , 数据库范式本身就存在级联概念,hibernate的级联就不是只有hibernate有,用sql 不用级联的么?你的where的语句本质不是级联么
5. 批量更新与缓存不一致, 读写分离 解决这问题 ,非要 大量的读和少量的写参和在一起,缓存不一致的问题,敢问你用肉眼能判断出来是你电脑内存不够了呢,还是本身缓存有问题。 读写分离 解决。
6. 配置繁琐, 这条也是扯淡的 ,jdbc 写一大堆sql繁琐不繁琐,凡事都是平衡的,得到一些东西必定意味着你要牺牲一些东西,你得到了开发容易,那么好你只能牺牲配置繁琐。
7. HQL,这条是面相对象惹的祸,其次我个人的看法,不一定准确:如果某人开发了一个产品,大家都喜欢封装,不让别人看到,那么hibernate也是,我做好了我就封装起来,我封装的代码要比屌丝程序员写的好,如果你想研究,那请你学习hibernate的源码
8. 太都查询方案,这条也扯淡,这叫灵活,不要太多查询方案,纯吹毛求si
9. N+1次查询, 这个确实是这样的,我也比较诟病这个问题
10. 性能问题,这个其实是有争议的,有人说大型项目用hibernate不行,可是某大型网站用的是hibernate,PV量也不少,也没见down掉。性能问题确实是仁者见仁智者见智,并且性能问题是个无底洞,没有最好只有更好,所以这个问题是个公共的问题。
总结:回复者里面有个人说了,没有失败的框架设计者,只有失败的程序员。我是比较赞同的, 框架只要精通,用的好,就可以解决问题,况且,市面上有很多项目是jdbc和hibernate并用的,sql大了就用jdbc,简单的东西直接用hibernate,一棒子打死,不科学,hibernate存在的时候,好多人都没学计算机呢,等你学完计算机了,hibernate还存在着。存在即价值,根本没有标准定义一个东西适合什么,一个东西不适合什么。这些个写框架的人都是行业里的翘楚,说白了,人家智商拿出来都比正常人多半斤,你考虑的常识问题人家还没考虑到,那不白混这么多年了。总之,hibernate是一款很实用的框架,尽管有一些使用方法在满足特定需求的时候是有些冗余,but条条大路通罗马通罗马,用hibernate遇到了这个问题,最先想到的不应该是放弃使用hibernate,而是如何在使用hibernate的基础把这个问题解决了,我敢保证,你使用其他的可能会解决你当前的这个问题,但是肯定会出现其他不是按照你的思路产生的问题,到时候怎么办,把那个框架再换了,最后使用jdbc,自己又嫌写sql太麻烦,太多,那就不要写程序了,歇着不麻烦,还不累。 回复 更多评论
@零雨其蒙
你说的不错Hibernate确实有很多好处,但是这些并不仅是hibernate独有的或者可以自己实现,那些思想是不错的,但是烦恼于在没有必要的时候去运行多余的工作,我只说性能实在太差了!
就比如说我只想返回一个Count(*),它就给我封装成一个List,我在解开其!单说没有连接数据库之前就创建了好多的对象,还没有考虑它的分析的过程呢,结束之后还是好多的对象来封装!
我的内存啊真是心疼啊!
一个复杂的系统必定有很多的任务,很多的线程,只从一次访问不能看出性能有多差,但是从整体角度看实在是头疼啊!
我知道用好其并不会出现多少问题,就是性能实在无法接受!
其实一个系统可以理解成在内存中处理数据的方法,hibernate是一个系统,他有的好处就是按照他固定的思维去做一些事情,所以实现了他的优点,但是有利就有弊,达到优点的本身就是一个不聪明的方法!这是必然的过程,如果没有缺点必定没有它的优点,如果一个系统优先考虑性能不能用hibernate,如果一个系统只考虑功能那就可以用hibernate!
哥说的有没有道理呢! 回复 更多评论
你说的不错Hibernate确实有很多好处,但是这些并不仅是hibernate独有的或者可以自己实现,那些思想是不错的,但是烦恼于在没有必要的时候去运行多余的工作,我只说性能实在太差了!
就比如说我只想返回一个Count(*),它就给我封装成一个List,我在解开其!单说没有连接数据库之前就创建了好多的对象,还没有考虑它的分析的过程呢,结束之后还是好多的对象来封装!
我的内存啊真是心疼啊!
一个复杂的系统必定有很多的任务,很多的线程,只从一次访问不能看出性能有多差,但是从整体角度看实在是头疼啊!
我知道用好其并不会出现多少问题,就是性能实在无法接受!
其实一个系统可以理解成在内存中处理数据的方法,hibernate是一个系统,他有的好处就是按照他固定的思维去做一些事情,所以实现了他的优点,但是有利就有弊,达到优点的本身就是一个不聪明的方法!这是必然的过程,如果没有缺点必定没有它的优点,如果一个系统优先考虑性能不能用hibernate,如果一个系统只考虑功能那就可以用hibernate!
哥说的有没有道理呢! 回复 更多评论
@ivan_xu
关于 8. 的见解我还是支持lz的,一直就有(“灵活”的很多种实现方案)与(单一的优质方案)的选择问题,有些人喜欢多而灵活的,有些人喜欢少儿方便的,但是实际就是绝大多数的时候,“多而灵活的方案”只能是给那些“程序研究人员”秀秀知识秀秀技术的,并不实用(他们最终也只会使用其中之一),那么既然如此其它的多种方案的存在除了可以学习还有什么用处呢?
应该说,“大而全的灵活”并不实用,而依据项目需求“小范围的灵活”是值得提倡的,并不见得多了就一定好,而从互联网软件技术的状况来说,多了实际是一定不好的
只是提一下,这个问题在对比脚本语言php,ruby,python的时候也是分成两大拨争论的 回复 更多评论
关于 8. 的见解我还是支持lz的,一直就有(“灵活”的很多种实现方案)与(单一的优质方案)的选择问题,有些人喜欢多而灵活的,有些人喜欢少儿方便的,但是实际就是绝大多数的时候,“多而灵活的方案”只能是给那些“程序研究人员”秀秀知识秀秀技术的,并不实用(他们最终也只会使用其中之一),那么既然如此其它的多种方案的存在除了可以学习还有什么用处呢?
应该说,“大而全的灵活”并不实用,而依据项目需求“小范围的灵活”是值得提倡的,并不见得多了就一定好,而从互联网软件技术的状况来说,多了实际是一定不好的
只是提一下,这个问题在对比脚本语言php,ruby,python的时候也是分成两大拨争论的 回复 更多评论
正是因为很多人,觉得复杂易错,所以放弃学习复杂框架的机会,而去使用简单易实现的东西,但是程序员不能决定自己将面对什么样的项目,而当面对一个hibernate可以完美解决问题的时候,恰恰因为你以前的放弃,而要绕很远的路 回复 更多评论