|
锁定老帖子 主题：再论hibernate是否适合做大型应用
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-18
coffeesweet 写道 很赞同楼主的观点，楼主并没没有明确说hibernate好和坏，只是建议对hibernate妄自发表评论的人先认真仔细的学习一下hibernate，你要说它好还是坏，至少你得知道它是不是确实不能干什么，或是能干什么吧，光学会用了几个API就大发感叹的人没有资格评论是好是坏.
我说的是这个意思，却引来好多人喷我，可能我伤了他们的自尊心吧 |
| 返回顶楼 | |
|
发表时间：2010-05-18
jameswxx 写道 zjcheng 写道 本人对Hibernate的理解不是很深，应该是很肤浅。但我认为Hibernate在CRUD操作比较多的情况下使用应该是比较好的，但是对于主要是查询的系统来讲，特别是复杂查询的时候应该不是好的选择，我觉得Ibatis倒是很好的选择。Hibernate的表和实体是对应的吧，那有的时候我想从某表中查找几十列，甚至是上百列的时候（这种时候是有的，特别是在电信等行业中，这种查询很多），难道还要定义上百个属性的实体吗，不知道我说的对不，在这上百个属性中，我们真正使用的可能就一两个属性，我想这样好像也不好，不知说的对否
并不是这样的，在定义映射文件的时候，你只需要映射你要查询出的字段就可以，你要查询什么字段你都能绝对掌控。 但是要配置这个文件的话，估计是很繁琐的吧，上百个字段啊，有简单的配置方式？ |
| 返回顶楼 | |
|
发表时间：2010-05-18
抛出异常的爱 写道 jameswxx 写道 大家给我凭了个新手帖，太伤我心了，呜呜。。。。。。
太不厚道了，不同意俺的说法也不用投新手帖吧 言之无物，纯为挑起论战的贴子 你看清楚，我说了我没有狂热支持hibernate，我只是说对hibernate发表评论之前，是否可以先对它深入的了解。我不是为了hibernate而讨论hibernate，由此引申开来，这是一种做事的态度，你说我这个是纯为挑起论战的帖子，你真是太高估我了，什么叫言之无物，我发表我的观点，这不是论文，是不是有几颗钻石就能让你能这么武断的甚至恶毒的给别人定论了？？？？所谓的资深人士？ |
| 返回顶楼 | |
|
发表时间：2010-05-18
zjcheng 写道 jameswxx 写道 zjcheng 写道 本人对Hibernate的理解不是很深，应该是很肤浅。但我认为Hibernate在CRUD操作比较多的情况下使用应该是比较好的，但是对于主要是查询的系统来讲，特别是复杂查询的时候应该不是好的选择，我觉得Ibatis倒是很好的选择。Hibernate的表和实体是对应的吧，那有的时候我想从某表中查找几十列，甚至是上百列的时候（这种时候是有的，特别是在电信等行业中，这种查询很多），难道还要定义上百个属性的实体吗，不知道我说的对不，在这上百个属性中，我们真正使用的可能就一两个属性，我想这样好像也不好，不知说的对否
并不是这样的，在定义映射文件的时候，你只需要映射你要查询出的字段就可以，你要查询什么字段你都能绝对掌控。 但是要配置这个文件的话，估计是很繁琐的吧，上百个字段啊，有简单的配置方式？ 很多工具可以生成hbm 但是我一般都会把那些XML更改一下以适应代码。 |
| 返回顶楼 | |
|
发表时间：2010-05-18
zjcheng 写道 jameswxx 写道 zjcheng 写道 本人对Hibernate的理解不是很深，应该是很肤浅。但我认为Hibernate在CRUD操作比较多的情况下使用应该是比较好的，但是对于主要是查询的系统来讲，特别是复杂查询的时候应该不是好的选择，我觉得Ibatis倒是很好的选择。Hibernate的表和实体是对应的吧，那有的时候我想从某表中查找几十列，甚至是上百列的时候（这种时候是有的，特别是在电信等行业中，这种查询很多），难道还要定义上百个属性的实体吗，不知道我说的对不，在这上百个属性中，我们真正使用的可能就一两个属性，我想这样好像也不好，不知说的对否
并不是这样的，在定义映射文件的时候，你只需要映射你要查询出的字段就可以，你要查询什么字段你都能绝对掌控。 但是要配置这个文件的话，估计是很繁琐的吧，上百个字段啊，有简单的配置方式？ 不会繁琐的，你可以看看hibernate开发手册，在这里我们不讨论hibernate具体用法，免得成了hibernate教程贴 |
| 返回顶楼 | |
|
发表时间：2010-05-18
不知道楼主，项目里都用了哪些hibernate的高级特性呢？我感觉这个框架还是主要用来规范架构，方便开发的。
|
| 返回顶楼 | |
|
发表时间：2010-05-18
最后修改：2010-05-18
gaojinpeng 写道 不知道楼主，项目里都用了哪些hibernate的高级特性呢？我感觉这个框架还是主要用来规范架构，方便开发的。
难道这还不够吗？ |
| 返回顶楼 | |
|
发表时间：2010-05-18
最后修改：2010-05-18
那对于那些复杂的查询，比如说我们会在使用特定数据库的时候，使用了其特性，比如Oracle，我们可能需要进行行列的转换，可能会用到Union等等，需要用到Oracle的一些特性才能高效地完成相关的查询的时候，使用hibernate来做的话，估计不会简单的，不知这些问题Hibernate怎么解决，对于这种主要是查询的用Hibernate好像没什么意义，不过这和楼主的主题好像也不是一个意思，哈哈，随便说了
|
| 返回顶楼 | |
|
发表时间：2010-05-18
jameswxx 写道 rockliu2009 写道 数据量和查询量都非常大的时候，SQL优化是非常关键的，SQL优化需要相当高的灵活性。hibernate恰恰在带来便利的同时阻挠了这种灵活性。它的自动化不利于对复杂的查询进行优化。ibatis允许开发人员自己优化SQL，牺牲便利带来了设计上的灵活性。选择框架应该根据自己所需要的业务，不是说hibernate一定不适合做大型开发，而是不适合做需要对SQL性能进行苛刻的优化的项目。楼主这篇贴的命题就不准确。
hibernate也提供了对原生sql的支持，能够让你绝对掌控sql。 的确 hibernate 提供的sql 支持。 但是在代码中散落的sql字符串组装， 你可知这个对于大型 长期项目意味着什么？ 意味着 难于修正。大型项目人员还是有一定流动性的。 过半年你去哪里找原来组装代码的人？ 我个人认为ibatis 提供的是对sql的统一管理，至少项目中的大部分sql都是独立在ibt文件里的 而不是散落在java代码里， 里面夹杂着无数字符串处理。 而提供的sql的便利性 只不过是附带的糖果罢了 |
| 返回顶楼 | |
|
发表时间：2010-05-18
当然 hibernate 提供了 多数据库支持 这个糖果对我个人来说 觉得是选择hibernate最大的原因。
至于查询上出的麻烦，也是可以靠修改数据库设计，增加中间数据转换 等方法来解决 其实不是谁好谁坏。 是项目情况 决定了技术框架。哦有时候还得加上 项目组的人员情况 |
| 返回顶楼 | |
