|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-19
javazeke 写道 有多少项目大到要换数据库的，，，炒作炒作就好了嘛。。
产品化的项目经常要根据客户的情况更换数据库 不一定大才要换... |
| 返回顶楼 | |
|
发表时间：2010-03-19
在做过的许多项目中 大多是阉割过的hibernate 使用hibernate各种关系的话 程序员对业务跟hibernate必须相当的理解 否则将加大开发跟维护难度
当然单纯的单表操作hibernate是优于jdbc的 |
| 返回顶楼 | |
|
发表时间：2010-03-19
最后修改：2010-03-19
这么说jdo也很好哇，也能加速开发(没有HQL不知道快不快..)，比hibernate更能跨数据库，而且还是一种规范，不喜欢这家实现可以换那家
|
| 返回顶楼 | |
|
发表时间：2010-03-19
skydream 写道 分享一下我们目前的做法，简单的说就是两条腿走路：
1. 对于性能敏感的地方，使用spring jdbc template 2. 对于性能不大敏感的地方，使用hibernate 一直觉得技术没有绝对的好与不好，关键在于用的地方是否合适。 hibernate对jdbcTemplate也是支持的。有些地方habernate执行效率低的话，就改用jdbc。 |
| 返回顶楼 | |
|
发表时间：2010-03-19
用spring jdbc template的飘过
|
| 返回顶楼 | |
|
发表时间：2010-03-19
aabcc 写道 javazeke 写道 有多少项目大到要换数据库的，，，炒作炒作就好了嘛。。
产品化的项目经常要根据客户的情况更换数据库 不一定大才要换... 换数据库？我们连数据库的版本都不敢换。 但是hibernate确实比较方便。 |
| 返回顶楼 | |
|
发表时间：2010-03-20
最后修改：2010-03-20
没觉出用hibernate会比用jdbc增加多少开发效率，
一个连jdbc都不会用的人开发人员让他用hibernate开发绝对是噩梦， 一个连sql都写不好的让他写hql更是大噩梦 |
| 返回顶楼 | |
|
发表时间：2010-03-20
脱离项目特性来谈论一个技术框架，似乎有点飘忽吧？
如果项目的特征是业务模型复杂，业务逻辑难度高（比如一些企业应用），那么hibernate可以让你的实现模型更贴近业务模型和分析模型，可以让你更关注于业务本身。 如果项目特征是大数据量，高性能要求，那么hibernate未必是最适合的选择。 还是那句话，没有银弹。关键需求和关键特性决定技术选型。 |
| 返回顶楼 | |
|
发表时间：2010-03-20
ps: 一下 hibernate的跨数据库其实不是100%跨，只能说80~90%跨，比如有些数据库不支持 top 这个关键字，hql里面写了就很郁闷了
|
| 返回顶楼 | |
|
发表时间：2010-03-20
linliangyi2007 写道 gdpglc 写道 我觉得 hibernate 还有一个很关键的用处，也是ORM框加的重要用处，帮助程序使用面向对象的方法来表达业务逻辑。而这正是hibernate的根本所在。不理解面向对象的人，理解hibernate是有困难的。如果只把对象作为库表内容的包装，这是一种肤浅的看法。hibernate要做的是使得业务逻辑的表达只要关注对象就可以了，而对象和数据库的关系，则由hibernate来维护。在理想状态下，业务逻辑可以不考虑数据库的访问（当然现实是做不到的），这就使得面象对象的思想得以实现。
只有有了这种关念，才能把握好 对象和库表的关系，尤其是对象间关系和库表间关系的差异和对应，才能理解hiberante的种种行为。只会用hibernate存取一个POJO，用面向过程的思维来理解hibernate这叫 暴殄天物 +1 , 楼主 和 楼上这位同学的观点都很到位 
建议大家看看领域驱动设计，还有马丁的几本老书，再来看Hibernate的设计，就知道hibernate的价值所在，以及设计成这样的原因了。 当然对hibernate了解到一定程度，完全可以跳出框框，只用你需要的部分，没必要用全hibernate中的所有功能啊。 |
| 返回顶楼 | |
