银行主数据项目(MDM)的数据持久层,你选择hibernate还是ibatis(MyBatis)

getclass

浏览: 43382 次
性别:
来自: 北京

最近访客更多访客>>

u012363178

naco

807081287

初阳最美_xm

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

数据库

Hibernate iBATIS 数据结构 JBPM JBoss

一个银行的主数据项目.数据数据持久层的实现上一直有争议.不知道,大家有没有什么好的建议.

主数据项目的模型设计,不是像交易类型的模型偏向三范式的.
举一个简单的场景,提供几个过滤条件,根据过滤条件查询结果并展现.这个数据的收集和过滤可能要涉及十几张表.

hibernate对这个功能的实现要用十几张表,就要用到十几个对象.这样提供过滤,并要整理清楚对象间的逻辑关系.对程序员的要求相对要高些.
如果用ibatis的话,程序员在ETL人员的协助下,一条sql就能很快解决问题.难度下降了不少.

另一个角度,性能上.hibernate的常用优化是第三方的二级缓存技术.可是,十几张表的关联几百万的数据量,自动生成的sql会有或多或少的问题.不如直接sql来的直接,可以在数据库层面直接优化.sql优化,索引,表分区等.

想听听大家对这个问题的看法

分享到：

SVN ‘XXXXXXXX\db\txn-current-lock’: 拒 ... | 已读书单

2011-06-09 01:02
浏览 4062
评论(68)
论坛回复 / 浏览 (87 / 49133)
分类:企业架构
查看更多

68 楼 Technoboy 2011-06-24

我们公司，FX外汇交易系统，数据库是MySQL，确实用的Hibernate,但无关联表，

67 楼 lwz5910 2011-06-24

技术没有好坏之分，要看用的人，用的场景等一系列的影响因素，要综合考量，而不是主观论断XX技术不行，举一个场景：要是客户一定要求用Hibernate或者Mybatis，你会反其道而行？

66 楼池中物 2011-06-24

liuwenjun05101 写道

支持mybatis
hibernate一般适合两种人，一种就是对hibernate非常了解的人，一种就是sql菜鸟，但是我相信一个团队非常了解hibernate的人还是极少的，像sql菜鸟来写东西，存在很大风险

sql菜鸟还能用ibatis？

65 楼 liuwenjun05101 2011-06-23

64 楼 george_space 2011-06-13

<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">这个是我说的，怎么引用时把我的名字给删除了？？？？ </div>
<div class="quote_div">
"并不是"hibernate不能简化开发“。"
我给你你总结过robin这样的结论么？
robin怎么认为那是他自己的观点，并不是robin说猴子没JJ，猴子就真的要憋死的。
 
既然你的观点是“ibatis+hibernate”，那你站在Hibernate 和 MyBatis哪边都能说自己有“特点”，这跟没有自己的主张是一样的。所以支持Hibernate的一方和支持MyBatis的一方都不能跟你理论了，因为你两边都靠拢，这怎么讨论？
 
 
</div>
 
 
大多数人讨论事情的时候引用别人的言论，是因为被引用的人有和自己的论点相近的结论，因而可以为辅助的论据。你说hibernate不能简化开发，然后又引用了robin的帖子，然后现在又说那是他自己的观点，与你的观点无关，你不觉得逻辑混乱么。
 
我的主张是各取所长，揉合在一起使用，非得像你一样一棒子打死一边，然后把另外一边捧到天上去才叫有主张？再说了，我的观点一直都是不能一棒子打死任何一个东西，是您要来和我讨论，要一棒子打死hib（见本贴你的第一次回复）。
 
再说下去就只剩下嘴仗而没有什么值得看的内容了。over.
</div>
robin的观点不是我引用的，我更不认同他的陈年老帖的观点。看清楚谁在拿robin的陈年老帖来为自己填充“论据”，ok? 
不要东一句引用，西一段戴错帽子。

在本贴中，我的观点自始至终都是一致，那就是：持久层采用MyBatis方案，肯定比采用Hibernate要好。不管是纯Hibernate，还是 Hibernate + X混搭。

63 楼梦秋雨 2011-06-13

<div class="quote_title"> </div>
<div class="quote_div">
"并不是"hibernate不能简化开发“。"
我给你你总结过robin这样的结论么？
robin怎么认为那是他自己的观点，并不是robin说猴子没JJ，猴子就真的要憋死的。
 
既然你的观点是“ibatis+hibernate”，那你站在Hibernate 和 MyBatis哪边都能说自己有“特点”，这跟没有自己的主张是一样的。所以支持Hibernate的一方和支持MyBatis的一方都不能跟你理论了，因为你两边都靠拢，这怎么讨论？
 
 
</div>
 


大多数人讨论事情的时候引用别人的言论，是因为被引用的人有和自己的论点相近的结论，因而可以为辅助的论据。你说hibernate不能简化开发，然后又引用了robin的帖子，然后现在又说那是他自己的观点，与你的观点无关，你不觉得逻辑混乱么。
 
我的主张是各取所长，揉合在一起使用，非得像你一样一棒子打死一边，然后把另外一边捧到天上去才叫有主张？再说了，我的观点一直都是不能一棒子打死任何一个东西，是您要来和我讨论，要一棒子打死hib（见本贴你的第一次回复）。

 
再说下去就只剩下嘴仗而没有什么值得看的内容了。over.

62 楼 supben 2011-06-13

<div class="quote_title">george_space 写道</div>
<div class="quote_div">
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">supben 写道</div>
<div class="quote_div">
<div class="quote_title">george_space 写道</div>
<div class="quote_div">
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
 
你不知道我说的级联是什么东西。推荐去看文档。
 
你说的级联，不是Hibernate级联删除、更新么？和数据库表的直接级联删除有区别么？求解？
 
Hib的级联和数据库的级联没有区别么？用hib的级联是把复杂性给了db？
 
 
恩，我说事实，我身处电信行业，3kw+的项目，使用我前面提到的技术方案，用hib简化了大多数场景下的更新，用ibatis原始sql精准的控制查询，项目很成功。所以我觉得这个方案还是可以的。在人力、效率、性能各方面算是一个比较好的均衡。Hibernate不是银弹，不可能搞定所有的事情，同样Ibatis也不是。是以趋利避害，各取其长。
 
我不觉得Hibernate 能简化什么开发，你说iBatis和Hibernate“各取其长”，这样谁还能反驳你呢，因为你根本没有选择自己的论点，难道你的论点是“iBatis + Hibernate就是我所主张的持久层方案”？
 
我的论点就是ibatis+hibernate，用ibatis作查询，用hib做保存更新，你反驳了半天不知道我的论点？这也需要“难道”？
 
你不觉得hib能简化开发的话，那么分别写一个ibatis和hibernate的映射比一下。依赖别人和自己掌握细节是一个平衡杆，robin所说的也是这个方面，并不是"hibernate不能简化开发“。
</div>
 
</div>
 http://robbin.iteye.com/blog/24529</div>
 
</div>
"并不是"hibernate不能简化开发“。"
我给你你总结过robin这样的结论么？
robin怎么认为那是他自己的观点，并不是robin说猴子没JJ，猴子就真的要憋死的。
 
既然你的观点是“ibatis+hibernate”，那你站在Hibernate 和 MyBatis哪边都能说自己有“特点”，这跟没有自己的主张是一样的。所以支持Hibernate的一方和支持MyBatis的一方都不能跟你理论了，因为你两边都靠拢，这怎么讨论？
</div>
 我的观点是 “ibatis+hibernate“？

61 楼 george_space 2011-06-13

<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">supben 写道</div>
<div class="quote_div">
<div class="quote_title">george_space 写道</div>
<div class="quote_div">
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
 
你不知道我说的级联是什么东西。推荐去看文档。
 
你说的级联，不是Hibernate级联删除、更新么？和数据库表的直接级联删除有区别么？求解？
 
Hib的级联和数据库的级联没有区别么？用hib的级联是把复杂性给了db？
 
 
恩，我说事实，我身处电信行业，3kw+的项目，使用我前面提到的技术方案，用hib简化了大多数场景下的更新，用ibatis原始sql精准的控制查询，项目很成功。所以我觉得这个方案还是可以的。在人力、效率、性能各方面算是一个比较好的均衡。Hibernate不是银弹，不可能搞定所有的事情，同样Ibatis也不是。是以趋利避害，各取其长。
 
我不觉得Hibernate 能简化什么开发，你说iBatis和Hibernate“各取其长”，这样谁还能反驳你呢，因为你根本没有选择自己的论点，难道你的论点是“iBatis + Hibernate就是我所主张的持久层方案”？
 
我的论点就是ibatis+hibernate，用ibatis作查询，用hib做保存更新，你反驳了半天不知道我的论点？这也需要“难道”？
 
你不觉得hib能简化开发的话，那么分别写一个ibatis和hibernate的映射比一下。依赖别人和自己掌握细节是一个平衡杆，robin所说的也是这个方面，并不是"hibernate不能简化开发“。
</div>
 
</div>
 http://robbin.iteye.com/blog/24529</div>
 
</div>
"并不是"hibernate不能简化开发“。"
我给你你总结过robin这样的结论么？
robin怎么认为那是他自己的观点，并不是robin说猴子没JJ，猴子就真的要憋死的。
 
既然你的观点是“ibatis+hibernate”，那你站在Hibernate 和 MyBatis哪边都能说自己有“特点”，这跟没有自己的主张是一样的。所以支持Hibernate的一方和支持MyBatis的一方都不能跟你理论了，因为你两边都靠拢，这怎么讨论？

60 楼 getclass 2011-06-13

友情提示:MyBatis的annotation,不支持复杂sql映射.(比如：嵌套 Join 映射)

59 楼梦秋雨 2011-06-13

george_space 写道

supben 写道

http://robbin.iteye.com/blog/24529

这是06年得老帖了，现在早已今非昔比。

06年的iBatis是不是“简陋”，我不知道，因为那时候我还在使用Hibernate，08年以后才开始用iBatis。
但是现在的MyBatis，早已不是“简陋”这两个字就能概括的了。

什么时候把数据库SQL层面上的分页这个事情内置了，然后再来谈简陋不简陋吧。

58 楼梦秋雨 2011-06-13

<div class="quote_title">supben 写道</div>
<div class="quote_div">
<div class="quote_title">george_space 写道</div>
<div class="quote_div">
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
 
你不知道我说的级联是什么东西。推荐去看文档。
 
你说的级联，不是Hibernate级联删除、更新么？和数据库表的直接级联删除有区别么？求解？
 
Hib的级联和数据库的级联没有区别么？用hib的级联是把复杂性给了db？
 
 
恩，我说事实，我身处电信行业，3kw+的项目，使用我前面提到的技术方案，用hib简化了大多数场景下的更新，用ibatis原始sql精准的控制查询，项目很成功。所以我觉得这个方案还是可以的。在人力、效率、性能各方面算是一个比较好的均衡。Hibernate不是银弹，不可能搞定所有的事情，同样Ibatis也不是。是以趋利避害，各取其长。
 
我不觉得Hibernate 能简化什么开发，你说iBatis和Hibernate“各取其长”，这样谁还能反驳你呢，因为你根本没有选择自己的论点，难道你的论点是“iBatis + Hibernate就是我所主张的持久层方案”？
 
我的论点就是ibatis+hibernate，用ibatis作查询，用hib做保存更新，你反驳了半天不知道我的论点？这也需要“难道”？
 
你不觉得hib能简化开发的话，那么分别写一个ibatis和hibernate的映射比一下。依赖别人和自己掌握细节是一个平衡杆，robin所说的也是这个方面，并不是"hibernate不能简化开发“。
</div>
 
</div>
 http://robbin.iteye.com/blog/24529</div>

57 楼 george_space 2011-06-13

supben 写道

http://robbin.iteye.com/blog/24529

56 楼 supben 2011-06-13

一个是ormapping ,一个是sql mapping。你的项目需要ORM不？

55 楼 supben 2011-06-13

http://robbin.iteye.com/blog/24529

54 楼 supben 2011-06-13

<div class="quote_title">george_space 写道</div><div class="quote_div"><div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
 
你不知道我说的级联是什么东西。推荐去看文档。
 
你说的级联，不是Hibernate级联删除、更新么？和数据库表的直接级联删除有区别么？求解？
 
 
 
恩，我说事实，我身处电信行业，3kw+的项目，使用我前面提到的技术方案，用hib简化了大多数场景下的更新，用ibatis原始sql精准的控制查询，项目很成功。所以我觉得这个方案还是可以的。在人力、效率、性能各方面算是一个比较好的均衡。Hibernate不是银弹，不可能搞定所有的事情，同样Ibatis也不是。是以趋利避害，各取其长。
 
我不觉得Hibernate 能简化什么开发，你说iBatis和Hibernate“各取其长”，这样谁还能反驳你呢，因为你根本没有选择自己的论点，难道你的论点是“iBatis + Hibernate就是我所主张的持久层方案”？
</div>
 </div> http://robbin.iteye.com/blog/24529

53 楼 george_space 2011-06-13

<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
 
你不知道我说的级联是什么东西。推荐去看文档。
 
你说的级联，不是Hibernate级联删除、更新么？和数据库表的直接级联删除有区别么？求解？
 
 
 
恩，我说事实，我身处电信行业，3kw+的项目，使用我前面提到的技术方案，用hib简化了大多数场景下的更新，用ibatis原始sql精准的控制查询，项目很成功。所以我觉得这个方案还是可以的。在人力、效率、性能各方面算是一个比较好的均衡。Hibernate不是银弹，不可能搞定所有的事情，同样Ibatis也不是。是以趋利避害，各取其长。
 
我不觉得Hibernate 能简化什么开发，你说iBatis和Hibernate“各取其长”，这样谁还能反驳你呢，因为你根本没有选择自己的论点，难道你的论点是“iBatis + Hibernate就是我所主张的持久层方案”？
</div>

52 楼梦秋雨 2011-06-13

另外，用不用Hibernate我觉得很大一个因素是考量数据结构的稳定性。不同的项目情况不同，显然不能一概而论说就是行或者不行。

51 楼梦秋雨 2011-06-13

不知道你说的“真正的系统”是什么玩意，我所知道的是我做的项目的确存在诸如用户、日志这样的窄表。或许您做的系统中每个表都是200来个字段吧。另外save/update在hibernate的级联下单表不单表是无所谓的。——额，默认你用过。
 
问：你的用户表有多窄，不会只有一个用户名跟密码吧？用户表不需要关联角色表、权限表、角色-权限映射表、部门表、职位表……这一堆东西么？级联？如果你的系统大量使用级联、触发器这样的数据库设计，成为“富DB”化的设计，我只能说：你把复杂的问题丢给了数据库，而不是Hibernate。如果只用Hibernate来操作一下日志表，它确实能胜任，哪个持久层框架不能胜任一个对业务统计精准性要求不高的区区的单表操作呢？
 
你不知道我说的级联是什么东西。推荐去看文档。
 
 
Hibernate做更新，基于JPA的注解映射实体类，对于绝大多数实体类只需要写很少的配置即可完成。您的mybatis要把一个查询映射到一个模型对象要写的mapping又如何，开发人员花心思对属性名和字段名，维护xml？复杂关联对象的映射又如何？
 
难道你没听说过MyBatis官方提供的生成器？
另外，MyBatis的SQL是可以写在Mapper类得annotation中的，维护你所说的属性名-字段名映射，比Hibernate复杂不到哪去。
复杂关联对象的映射？MyBatis手册中有专门一个章节来讲对象类型属性映射和集合类型属性的映射，我不觉得MyBatis处理对象类型的属性和集合类型的属性有多复杂，起码我可以自由控制从子表“拉”过来几个字段，按照什么条件“拉过来”。我可以对自己写的SQL语句竭尽所能地优化。
 
你又跑偏了，查询我也是倾向于ibatis的。此外，招聘人员的时候，能够熟练应用hibernate annotation定义映射的人，远多于能够熟练使用mybatis annotation的人。
 
另外，拿最原始的jdbc做查询，自己分析resultset做转换能不能搞定ibatis搞定的所有问题？那么既然jdbc能搞定ibatis能解决的和解决不了的所有问题，那么您是不是该用jdbc呢？或者直接用socket去和数据库通信？
 
既然MyBatis已经做好了JDBC结果集和实体类的映射，为什么要自己再折腾一次？难道自己折腾的一定能比MyBatis效率要高？
 
没看明白这是反语？hib的映射比ibatis简单，那为什么要用ibatis呢。注意我主要说的是更新的场景。你可以写两个有关联的实体类比比两个方案映射配置代码量。
 
3、“
<div class="quote_title" style="font-weight: bold; margin-top: 5px; margin-right: 0px; margin-bottom: 0px; margin-left: 15px; padding: 5px;">梦秋雨写道</div>
<div class="quote_div" style="margin-top: 0px; margin-right: 5px; margin-bottom: 5px; margin-left: 15px; background-color: #fafafa; padding: 3px; border: 1px solid #cccccc;">
<div class="quote_title" style="font-weight: bold; margin-top: 5px; margin-right: 0px; margin-bottom: 0px; margin-left: 15px; padding: 5px;">evanzzy 写道</div>
<div class="quote_div" style="margin-top: 0px; margin-right: 5px; margin-bottom: 5px; margin-left: 15px; background-color: #fafafa; padding: 3px; border: 1px solid #cccccc;">动钱的系统绝不能用hibernate，切记切记。IBatis或Spring JdbcTemplate都可以</div>
 这种自己没用明白于是觉得不好用，然后就出来喷的人…… ……”</div>
问：既然你弄明白了，说说你“动钱”的部分是怎么用Hibernate来“弄明白的”，简单举个例子：查询A省所有储蓄卡金额不足306元，并且持续时间6个月以上，并且在本行开户多于2次的男性用户的前三个月的交易总额、支出总额和存入总额……
类似这样的查询，在实际的系统中n多，使用hibernate，我真不知道如何方便地搞定而又不需要查出一堆多余的数据。表结构都是设计好的，不要说什么细颗粒度的小表这类的前提，真正的系统中，不可能给你三两个字段做一个表。
 
我们查询用的是Ibatis。
那就不用讨论了，我也主张MyBatis。
--------------------------------------------------------------------------------------------------------------------------
 
如果不在Hibernate中使用原生SQL语句，只纯粹让Hibernate面向对象去挑大梁，那无异于开着坦克爬梯子；
如果在Hibernate应用中大量使用原生SQL，那为什么不直接使用MyBatis，将SQL统一安放在Mapper文件中，或者annotation中，同时做到了数据集和实体类的映射，实现了面向对象方式直接操作SQL。
 
直接使用Spring JDBCTemplate 也比Hibernate + 原生SQL，或者 Hibernate + MyBatis混搭这样的设计要好。
 
技术选型要兼顾设计目标和团队人员情况，而且每个框架都有其适用范围，也许在你所在的团队里面你的做法是合适的，但是你无法判断我所在团队的情况。另外，一棒子打死全世界目前使用人数最多的o/r mapping框架，真是认为举世皆浊你独清啊。
我也没建议你用MyBatis啊，我只是个人觉得：银行类、电信类应用，持久层最好使用MyBatis，Hibernate自己纯面向对象的方式是很难搞定的。

 
恩，我说事实，我身处电信行业，3kw+的项目，使用我前面提到的技术方案，用hib简化了大多数场景下的更新，用ibatis原始sql精准的控制查询，项目很成功。所以我觉得这个方案还是可以的。在人力、效率、性能各方面算是一个比较好的均衡。Hibernate不是银弹，不可能搞定所有的事情，同样Ibatis也不是。是以趋利避害，各取其长。

50 楼 damoqiongqiu 2011-06-13

电信行业，好久不用Hibernate的淡淡飘过
自从有了IBatis，从未感觉到Hibernate有什么好
尤其大数据量、实时性要求高的系统

49 楼 george_space 2011-06-13

<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">george_space 写道</div>
<div class="quote_div">
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">getclass 写道</div>
<div class="quote_div">
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">evanzzy 写道</div>
<div class="quote_div">动钱的系统绝不能用hibernate，切记切记。IBatis或Spring JdbcTemplate都可以</div>
 这种自己没用明白于是觉得不好用，然后就出来喷的人…… 本人所处项目持久层使用Hibernate+Ibatis，Ibatis做查询、统计、报表，Hibernate负责更新、保存。20人+的项目，也走的很顺利。 另，该项目里面是要算钱的。</div>
 
还可以这么架构呢,什么情况.兄弟们来说说这个吧.
</div>
 
Service里面注入两个Dao，一个Hibernate的，一个Ibatis的。提供一系列查询方法：findXxByNamedQuery，我们抛弃了hibernate的namedQuery，service提供的namedQuery方法一律使用ibatis做查询，第一个参数就是ibatis select的名称，返回结果大多数是Map<String,Object>的集合。Ibatis主要使用与如下场景：
 
1.宽表或者复杂关联情况下的列表页面展现，要展现的列数远小于实体类的属性个数，使用ibatis减少无谓的加载
2.针对某一db的sql优化
3.报表、统计等用sql来做比较自然的东西
 
所以只是用了ibatis的查询，基本上没有用它的映射。
 
Hibernate负责窄表管理，以及绝大多数的save/update。
</div>
 好，现在就说说道理：
1、“Hibernate负责窄表管理，以及绝大多数的save/update”
问：一个真正的系统中，有多少应用是“窄表”增删改查，我做过的系统，多数情景下是多表联查、多表复杂统计、save/update也很少是单表操作的；
 
不知道你说的“真正的系统”是什么玩意，我所知道的是我做的项目的确存在诸如用户、日志这样的窄表。或许您做的系统中每个表都是200来个字段吧。另外save/update在hibernate的级联下单表不单表是无所谓的。——额，默认你用过。
 
问：你的用户表有多窄，不会只有一个用户名跟密码吧？用户表不需要关联角色表、权限表、角色-权限映射表、部门表、职位表……这一堆东西么？级联？如果你的系统大量使用级联、触发器这样的数据库设计，成为“富DB”化的设计，我只能说：你把复杂的问题丢给了数据库，而不是Hibernate。如果只用Hibernate来操作一下日志表，它确实能胜任，哪个持久层框架不能胜任一个对业务统计精准性要求不高的区区的单表操作呢？
 
 
2、“Service里面注入两个Dao，一个Hibernate的，一个Ibatis的。针对某一db的sql优化报表、统计等用sql来做比较自然的东西……”
问：是不是Hibernate搞不定，或者说不容易搞定的部分，使用iBatis来搞定？如果是，既然iBatis可以搞定简单部分，也可以搞定Hibernate搞不定（或者说不容易搞定）的部分，那么为什么不直接使用iBatis（现在已经是MyBatis了），要Hibernate何用？
 
Hibernate做更新，基于JPA的注解映射实体类，对于绝大多数实体类只需要写很少的配置即可完成。您的mybatis要把一个查询映射到一个模型对象要写的mapping又如何，开发人员花心思对属性名和字段名，维护xml？复杂关联对象的映射又如何？
 
难道你没听说过MyBatis官方提供的生成器？
另外，MyBatis的SQL是可以写在Mapper类得annotation中的，维护你所说的属性名-字段名映射，比Hibernate复杂不到哪去。 
复杂关联对象的映射？MyBatis手册中有专门一个章节来讲对象类型属性映射和集合类型属性的映射，我不觉得MyBatis处理对象类型的属性和集合类型的属性有多复杂，起码我可以自由控制从子表“拉”过来几个字段，按照什么条件“拉过来”。我可以对自己写的SQL语句竭尽所能地优化。
 
另外，拿最原始的jdbc做查询，自己分析resultset做转换能不能搞定ibatis搞定的所有问题？那么既然jdbc能搞定ibatis能解决的和解决不了的所有问题，那么您是不是该用jdbc呢？或者直接用socket去和数据库通信？
 
既然MyBatis已经做好了JDBC结果集和实体类的映射，为什么要自己再折腾一次？难道自己折腾的一定能比MyBatis效率要高？
 
3、“
<div class="quote_title">梦秋雨写道</div>
<div class="quote_div">
<div class="quote_title">evanzzy 写道</div>
<div class="quote_div">动钱的系统绝不能用hibernate，切记切记。IBatis或Spring JdbcTemplate都可以</div>
 这种自己没用明白于是觉得不好用，然后就出来喷的人…… ……”</div>
问：既然你弄明白了，说说你“动钱”的部分是怎么用Hibernate来“弄明白的”，简单举个例子：查询A省所有储蓄卡金额不足306元，并且持续时间6个月以上，并且在本行开户多于2次的男性用户的前三个月的交易总额、支出总额和存入总额……
类似这样的查询，在实际的系统中n多，使用hibernate，我真不知道如何方便地搞定而又不需要查出一堆多余的数据。表结构都是设计好的，不要说什么细颗粒度的小表这类的前提，真正的系统中，不可能给你三两个字段做一个表。
 
我们查询用的是Ibatis。
那就不用讨论了，我也主张MyBatis。
--------------------------------------------------------------------------------------------------------------------------
 
如果不在Hibernate中使用原生SQL语句，只纯粹让Hibernate面向对象去挑大梁，那无异于开着坦克爬梯子；
如果在Hibernate应用中大量使用原生SQL，那为什么不直接使用MyBatis，将SQL统一安放在Mapper文件中，或者annotation中，同时做到了数据集和实体类的映射，实现了面向对象方式直接操作SQL。
 
直接使用Spring JDBCTemplate 也比Hibernate + 原生SQL，或者 Hibernate + MyBatis混搭这样的设计要好。
 
技术选型要兼顾设计目标和团队人员情况，而且每个框架都有其适用范围，也许在你所在的团队里面你的做法是合适的，但是你无法判断我所在团队的情况。另外，一棒子打死全世界目前使用人数最多的o/r mapping框架，真是认为举世皆浊你独清啊。
我也没建议你用MyBatis啊，我只是个人觉得：银行类、电信类应用，持久层最好使用MyBatis，Hibernate自己纯面向对象的方式是很难搞定的。
 
以上是个人愚见。
 
</div>
 
 
</div>

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论