|
锁定老帖子 主题：hibernate在新项目上应用的弊端
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-26
似乎你的抱怨都是hibernate的优点。。。。
|
| 返回顶楼 | |
|
发表时间：2011-04-26
EdwardWorld 写道 sheep3600 写道 EdwardWorld 写道 KimShen 写道 newslxw 写道 首先，我并不是一个hibernate开发的推崇者，也不精通hibernate，只是在某几个项目上用到了hibernate，下面是我的感受: 1、lazy加载，经常带来问题 2、级联保存常带来问题，所以我开发是都不用级联保存 3、主键的native要求主键使用number类型，给设计带来麻烦 4、很多人开发是不设计表结构，而是用hibernate来生产数据库，对维护带来很多影响 5、处理复杂SQL，还是需要用SQL而不能用HQL，导致语言混杂，增加维护成本 6、大数据量时，很容易出现问题 7、不适合新人使用，项目中往往有工作经验较低的人，使用hibernate往往容易出错 我对持久层框架要求很简单： 1、自动POJO到数据，或者数据库到POJO 2、适度缓存 如果不是项目要求，我更倾向选择ibatis。 1,没说要强制lazy 2,级联保存不代表数据库就是级联的.而且请举例问题? 3,我怎么不知道主键强制使用number,那你们是用什么? 4,正向工程和逆向工程是你自己选择的 5,你来句SQL,只要你表设计是合理的我就能用HQL或者QBC帮你写出来.写不出来十有八九是数据表设计有问题 6,大量是多少?我们查询40w条数据也没发现问题么?难道不用分页? 7,这个我认同 综上所述,你的感受大多数是因为你也不熟悉Hibernate.我不反对MyBatis,但是MyBatis还不如DBUtils和SpringJDBC Template ------------------------------------------------------------------ 表一：用户登记表(USER_INFO) 引用 主键 用户名 userId userName 表二：角色表(USER_ROLE) 引用 主键 角色名 roleCode roleName 表三：用户－角色映射表(USER_ROLE_MAPPING) 引用 用户ID 角色ID userId roleCode 表四：权限表(USER_PERMISSION) 引用 权限ID 权限名称 permissionCode permissionName 表五：角色权限映射表(ROLE_PERMISSION_MAPPING) 引用 角色ID 权限ID roleCode permissionCode 表五点二：用户权限直接映射表(USER_PERMISSION_MAPPING) 引用 用户ID 权限ID userId permissionCode 表六：产品订单表(PROD_ORDER) 引用 订单ID 创建日期 orderId lastUpdateTime 表七：产品登记表(PROD_PRODUCT) 引用 产品ID 产品名称 产品单价 折扣 实价 prodId prodName price discount actual_prices 表八：产品－产品订单映射表(PROD_PRODUCT_ORDER_MAPPING) 引用 产品ID 订单ID 购买数量 本类产品价格总计 prodId orderId prodQuantity totalPrice 其他表：用户组表、订单分类表、产品分类表、订单流转记录表、部门表、职位表、用户部门映射表…… 问题： 请查询角色编码是“salesman”，并且拥有“sellingCars”权限，本月销售奥迪A6产品超过100辆，且实际单价不低于50万的用户的前三十名。 上面这些表是我临时设计的，可能有些地方不合理，但是应该是普通软件中比较常见的应用情景，请问阁下如何使用Hibernate来实现上述查询？求教。 试试考虑下视图和Assigned。 很多涉及到数据库的应用，都不能完全使用Hibernate来但当持久层；但是所有的涉及到数据库的应用，都可以100%使用SQL(直接使用，或者自己封装，或者直接使用MyBatis)来实现，这就是问题所在。也就是说，Hibernate完全抛弃了原生SQL，只是个独臂大侠。 Hibernate完全抛弃了原生SQL?? 没听说过。 请参见 http://docs.jboss.org/hibernate/core/3.6/reference/zh-CN/html/querysql.html amonlei 写道 有这么一句话：没有不好的景色只有不好的摄影师。楼主武艺不精，全赖刀上了。hibernate不是刚出来的东西。
如楼上所说，功夫不好，就怨武器不行。有人拿菜刀就可以屠龙，有人拿屠龙刀却被龙屠。 多花点时间认真看看Start Guide, Reference。你的问题95%在里面都能找到答案或提示。剩下5% Google可以告诉你。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
很有同感，在我们公司技术选型也有很多声音，有些同事或者低调不作声；
其实个人认为hibernate是把双刃剑，它应该很成熟，就看你的领悟程度，新手或经验不足 还是慎用，或用它最基本的面，不用级联，不用缓存，只用get，也不失时明智的选择！ |
| 返回顶楼 | |
|
发表时间：2011-04-26
hibernate强大是毋庸置疑的，对开发者的要求也高，数据库最好要设计到第三范式，级联查询、保存时候你就体会到。
|
| 返回顶楼 | |
|
发表时间：2011-04-26
有时候数据库设计太细，圈复杂度就上去了，前一个组件的圈复杂度达到158，oh, my god.
|
| 返回顶楼 | |
|
发表时间：2011-04-26
最后修改：2011-04-26
Edward 写道 EdwardWorld 写道 sheep3600 写道 EdwardWorld 写道 KimShen 写道 newslxw 写道 首先，我并不是一个hibernate开发的推崇者，也不精通hibernate，只是在某几个项目上用到了hibernate，下面是我的感受: 1、lazy加载，经常带来问题 2、级联保存常带来问题，所以我开发是都不用级联保存 3、主键的native要求主键使用number类型，给设计带来麻烦 4、很多人开发是不设计表结构，而是用hibernate来生产数据库，对维护带来很多影响 5、处理复杂SQL，还是需要用SQL而不能用HQL，导致语言混杂，增加维护成本 6、大数据量时，很容易出现问题 7、不适合新人使用，项目中往往有工作经验较低的人，使用hibernate往往容易出错 我对持久层框架要求很简单： 1、自动POJO到数据，或者数据库到POJO 2、适度缓存 如果不是项目要求，我更倾向选择ibatis。 1,没说要强制lazy 2,级联保存不代表数据库就是级联的.而且请举例问题? 3,我怎么不知道主键强制使用number,那你们是用什么? 4,正向工程和逆向工程是你自己选择的 5,你来句SQL,只要你表设计是合理的我就能用HQL或者QBC帮你写出来.写不出来十有八九是数据表设计有问题 6,大量是多少?我们查询40w条数据也没发现问题么?难道不用分页? 7,这个我认同 综上所述,你的感受大多数是因为你也不熟悉Hibernate.我不反对MyBatis,但是MyBatis还不如DBUtils和SpringJDBC Template ------------------------------------------------------------------ 表一：用户登记表(USER_INFO) 引用 主键 用户名 userId userName 表二：角色表(USER_ROLE) 引用 主键 角色名 roleCode roleName 表三：用户－角色映射表(USER_ROLE_MAPPING) 引用 用户ID 角色ID userId roleCode 表四：权限表(USER_PERMISSION) 引用 权限ID 权限名称 permissionCode permissionName 表五：角色权限映射表(ROLE_PERMISSION_MAPPING) 引用 角色ID 权限ID roleCode permissionCode 表五点二：用户权限直接映射表(USER_PERMISSION_MAPPING) 引用 用户ID 权限ID userId permissionCode 表六：产品订单表(PROD_ORDER) 引用 订单ID 创建日期 orderId lastUpdateTime 表七：产品登记表(PROD_PRODUCT) 引用 产品ID 产品名称 产品单价 折扣 实价 prodId prodName price discount actual_prices 表八：产品－产品订单映射表(PROD_PRODUCT_ORDER_MAPPING) 引用 产品ID 订单ID 购买数量 本类产品价格总计 prodId orderId prodQuantity totalPrice 其他表：用户组表、订单分类表、产品分类表、订单流转记录表、部门表、职位表、用户部门映射表…… 问题： 请查询角色编码是“salesman”，并且拥有“sellingCars”权限，本月销售奥迪A6产品超过100辆，且实际单价不低于50万的用户的前三十名。 上面这些表是我临时设计的，可能有些地方不合理，但是应该是普通软件中比较常见的应用情景，请问阁下如何使用Hibernate来实现上述查询？求教。 试试考虑下视图和Assigned。 很多涉及到数据库的应用，都不能完全使用Hibernate来但当持久层；但是所有的涉及到数据库的应用，都可以100%使用SQL(直接使用，或者自己封装，或者直接使用MyBatis)来实现，这就是问题所在。也就是说，Hibernate如果完全抛弃了原生SQL，只是个独臂大侠。 Hibernate完全抛弃了原生SQL?? 没听说过。 请参见 http://docs.jboss.org/hibernate/core/3.6/reference/zh-CN/html/querysql.html amonlei 写道 有这么一句话：没有不好的景色只有不好的摄影师。楼主武艺不精，全赖刀上了。hibernate不是刚出来的东西。
如楼上所说，功夫不好，就怨武器不行。有人拿菜刀就可以屠龙，有人拿屠龙刀却被龙屠。 多花点时间认真看看Start Guide, Reference。你的问题95%在里面都能找到答案或提示。剩下5% Google可以告诉你。 我的意思是“如果Hibernate不使用原生SQL，只是个独臂大侠”，而不是说“Hibernate中不能使用原生SQL”。 在Hibernate中使用原生SQL，完成Hibernate不善于完成的功能，然后把这一切都说是Hibernate的伟大，是不是把原生SQL的贡献强加给了Hibernate? 每当有人抱怨Hibernate的时候，总是有“大侠”跳出来说：“其实Hibernate中可以使用原生SQL，也就是Hibernate混搭SQL”。 是的，他们确实可以混搭，不过我想楼主抱怨的是“Hibernate不混搭原生SQL”的情况。 如果考虑Hibernate混搭原生SQL，那讨论这个帖子还有什么意义，Hibernate已经是继承了纯SQL的所有特点了，它已经是天下无敌了。 另：你来回复我的帖子，外人看了好像我是你的马甲，^_^。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
我看楼主的问题，大多是你要往不好的地方使用hibernate啊，没人强迫你一定要这么用。关于SQL的问题，我想什么工具都没有万能的，复杂的语句用SQL又有什么呢？80%是简单语句。
不要告诉我你们写hibernate的工程师，连SQL语句都不会，只会SQL |
| 返回顶楼 | |
|
发表时间：2011-04-26
hua0424 写道 我看楼主的问题，大多是你要往不好的地方使用hibernate啊，没人强迫你一定要这么用。关于SQL的问题，我想什么工具都没有万能的，复杂的语句用SQL又有什么呢？80%是简单语句。
不要告诉我你们写hibernate的工程师，连SQL语句都不会，只会SQL 很好很强大，每当有人抱怨Hibernate时，总会有人站出来说“其实Hibernate可以和SQL混搭”。 使得，他们确实可以混搭，不过我想楼主抱怨的是Hibernate不混搭纯SQL的情况。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
hibernate很优秀 呵呵
只是越发展越灵活 |
| 返回顶楼 | |
|
发表时间：2011-04-26
各有优缺点吧，我觉得Spring jdbc还是很适合楼主的。
|
| 返回顶楼 | |
