|
锁定老帖子 主题：hibernate在新项目上应用的弊端
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-27
你们这些N人为何要老钻牛角尖呢？技术都是为业务服务的，能解决问题就行，并不是说用了hibernate就连sql都不用了，那你用数据库做啥呢？
|
| 返回顶楼 | |
|
发表时间：2011-04-27
caomeiliang 写道 buydzyj 写道 hibernate不适合业务逻辑复杂的系统
请问这样的存储过程如何用Hql实现？ 我很想知道你用jdbc或者ibatis写这个存储过程咋写？别告诉我用CallStatement 先搞清楚概念：存储过程是在数据库中写，不在jdbc或者ibatis中写；CallStatement也不是写存储过程，只是调用存储过程。还有，是CallableStatement，而不是CallStatement。 具体实现我们自己对jdbc访问存储过程进行了封装，通过反射与泛型，定义好了存储过程入口对象与返回对象，自动完成对对象的封装。 |
| 返回顶楼 | |
|
发表时间：2011-04-27
我觉得LZ应该是对hibernate不是很清楚才会这样，毕竟一个东西有好的一面也有它不好的一面，所有的都是有利有弊的,要看自已怎么用了
|
| 返回顶楼 | |
|
发表时间：2011-04-27
我一直认为hibernate是个比较好用的特性缓存
对于大量数据运算的统计报表,hibernate没什么优点 |
| 返回顶楼 | |
|
发表时间：2011-04-27
最后修改：2011-04-27
貌似没有一个人提到了数据库迁移的问题
如果你的系统跟数据库耦合度这么高， 人家从oracle要更换到DB2， 你的代码修改量会有多大？ 还有，hb只是一个持久层的架构， 我看大家讨论的东西，感觉大家把hb都过多的参与到逻辑层， 额... 让我有种把裤衩当帽子感觉，虽然能戴上， 可是他看起来很别扭，甚至很恶心 一个系统框架，仅仅靠ssh，来搭建起来， 其他的地方逻辑架构混乱， 就跟只有一个房架，没打地基一样 还有感觉大家都太过依赖于数据库的计算而放弃了程序的计算 有一些逻辑运算，可以放到程序之中，来做一些解耦 有一些大幅度的运算可以构建视图或者存储过程， 为什么有了HB就想把所有的东西都放在hb里面呢？ 还有一点，你是吧hb当核心了还是把hb当工具了呢？ |
| 返回顶楼 | |
|
发表时间：2011-04-27
xiaotot 写道 貌似没有一个人提到了数据库迁移的问题
如果你的系统跟数据库耦合度这么高， 人家从oracle要更换到DB2， 你的代码修改量会有多大？ 还有，hb只是一个持久层的架构， 我看大家讨论的东西，感觉大家把hb都过多的参与到逻辑层， 额... 让我有种把裤衩当帽子感觉，虽然能戴上， 可是他看起来很别扭，甚至很恶心 一个系统框架，仅仅靠ssh，来搭建起来， 其他的地方逻辑架构混乱， 就跟只有一个房架，没打地基一样 还有感觉大家都太过依赖于数据库的计算而放弃了程序的计算 有一些逻辑运算，可以放到程序之中，来做一些解耦 有一些大幅度的运算可以构建视图或者存储过程， 为什么有了HB就想把所有的东西都放在hb里面呢？ 貌似用得起付费Oracle或者DB2的企业，都是不可能轻易换掉软件的DB的，甚至连版本都不敢换，Hibernate在中小型产品类应用上还有一些用武之地。 |
| 返回顶楼 | |
|
发表时间：2011-04-27
最后修改：2011-04-27
楼上
如果是从mysql升级到sqlserver 呢？ |
| 返回顶楼 | |
|
发表时间：2011-04-27
同过表设计简化HQL，而不是一味的写复杂的SQL语句。
|
| 返回顶楼 | |
|
发表时间：2011-04-27
danan2008 写道 确实，hibernate对于新手来说，很容易犯错误。没有什么好与不好的技术，都是相对于而言的。
但是hibernate的错误没有其他的技术明显，有些到了发布后才发现，而且往往导致系统性能低下，这样一整就导致整个项目的成本提高了 |
| 返回顶楼 | |
|
发表时间：2011-04-27
neptune 写道 hibernate要用在新的项目上，表结构要自己设计好（可控）。如果是遗留系统还是ibatis吧。
遗留系统往往已经用了hibernate |
| 返回顶楼 | |
