- 浏览: 274145 次
- 性别:
- 来自: 北京
最新评论
-
lishen:
caomeiliang 写道ibatis需要写SQLibati ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
caomeiliang:
ibatis需要写SQLibatis需要写SQLibatis需 ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
yp0123456789:
这篇文章是假定h没有namesql和execute的基础之上写 ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
abc382410124:
jiming 写道引用 jeffrey_gao 5 小 ...
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议) -
wpc009:
我觉得Netty的卖点一是NIO, 二是事件驱动。 这在高并发 ...
Netty 性能测试(与Tomcat 对比)
[注意]清在回复之前认真地看一下我的帖子,结合你的实际项目经验考虑一下,看看你是否能比较好地解决我所提出的Hibernate 的缺点。最好不要提一些大家都知道的泛泛的观点,这样会很浪费读者的时间并且分散大家的注意力。
非常感谢有几位对 hibernate 有深入了解的朋友给出了我这里提出的问题的 hibernate 解决方案。我提出这几个问题的初衷不是说 hibernate 无法实现这些功能。而是说他的实现比较不美,呵呵。比如说把一些 sql 嵌入到 java 代码中,我觉得这是非常不好的习惯。
v0.3 - 2007-1-1 21:1:1
我在最初的选型的时候是打算选择 Hibernate 的,在研究的过程中发现了 iBatis,经过
分析比较之后我选择了 iBatis。现在我已经使用 iBatis 完成了一个中小型的项目。这个
项目在性能、可维护性、可扩展性方面都非常令我满意。
在这个过程中我也不断的与使用过或者正在使用 Hibernate 的人进行过探讨。而且我本身
也在不断的跟进 Hibernate 的发展。
最终,我的结论是 iBatis 的选择非常正确,而且越用越喜欢它了。
当然了,我对 Hibernate 的理解还是非常有限的,所以这里的关于 Hibernate 的一些观
点的错误之处希望能够得到 Hibernate 高手的指正。
1. iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。
Hibernate 可能需要 3 倍以上的时间来掌握。
2. iBatis 更容易进行 sql 的 优化。
这个应该大家都有共识了。另外 Hibernate 生成的 sql 也实在是太难看了。鉴
于有的朋友提到了 sql 不太重要。我想在这里强调一下我的经验,一般系统性能
的瓶颈都在数据库上。所以这一点是 iBatis 非常重要的一个优势。
3. iBatis 可以进行细粒度的优化
3.1 比如说我有一个表,这个表有几个或者几十个字段,我需要更新其中
的一个字段,iBatis 很简单,执行一个sql
UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
但是用 Hibernate 的话就比较麻烦了,缺省的情况下 hibernate 会更新所有字段。
当然我记得 hibernate 有一个选项可以控制只保存修改过的字段,但是我不太确
定这个功能的负面效果。
3.2 我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据
库读很多数据,节省流量
SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
3.2.1 一般情况下
Hibernate 会把所有的字段都选出来。比如说有一个上面表有8个字段,
其中有一两个比较大的字段,varchar(255)/text。上面的场景中我为什么要把他
们也选出来呢?
3.2.2 用 hibernate 的话,你又不能把这两个不需要的字段设置为 lazy load,因
为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出
ibatis 的好处了
3.2.3 Hibernate 还有一个方案,就是生成 javabean/map/object[](感谢
leelun/cjmm),但是这样的话就可能会产生大量的多余 class。map/object[] 的方式
应该不错,我比较喜欢这种方式。
3.3 如果我需要更新一条记录(一个对象),如果使用 hibernate,需要现把对
象 select 出来,然后再做 update。这对数据库来说就是两条 sql。而 iBatis
只需要一条 update 的 sql 就可以了。减少一次与数据库的交互,对于性能的
提升是非常重要。
4. 开发方面
4.1 开发效率上,我觉得两者应该差不多
4.2 可维护性方面,我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到
单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保存
sql/hql。
5. 运行效率
5.1 在不考虑 cache 的情况下,iBatis 应该会比hibernate 快一些或者很多
(根据实际情况会有所不同)。
当然 iBatis 也有比较大的缺点
1. 不同数据库类型的支持不好,如果你要开发的系统是要在对中数据间移植,那可能用 hibernate 比较好。
2. 缺省的 cache 支持不好,但是 hibernate 的 cache 支持其实也不是很好,而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理 cache。
非常感谢这么多朋友对这个话题很感兴趣。但是我感觉大家并没有对我第三部分提到的问题进行更深入的思考。我晚些时候会提交一些 ibatis 的代码。欢迎大家一起来讨论。
千万别把煽动这个大帽子给我口到头上来,赫赫。
其实我对 Hibernate 也进行了相当多的研究。而且应该比很多现在在用 Hibernate 的人要强一些,当然不包括一些大牛门了。
我之所以这么提在我的文章里分析已经很清楚了。我没有否认 hibernate 是一个非常优秀的项目,其中所包含的理论水平也的确比 ibatis 高深和先进一些。但是可能有点太过理论化而忽略了一些实际项目中的非常重要的考虑点。
OO 很好,但是也不要到处都用 OO。
我们一定要非常注意避免过度设计。
从你的分析来看,我觉得你可以稍微花点时间在如何解决你所分析出来的问题上面。你所提到的问题都是可以解决的。
ORM框架各有各的好处,不用过分强调谁行谁不行。老实说,iBatis在做持久化的笨拙就令人受不了。一张表有30个字段,你用ibatis去做一次insert试试?不过在查询方面,iBatis的确有很多优势的地方。
千万别把煽动这个大帽子给我口到头上来,赫赫。
其实我对 Hibernate 也进行了相当多的研究。而且应该比很多现在在用 Hibernate 的人要强一些,当然不包括一些大牛门了。
我之所以这么提在我的文章里分析已经很清楚了。我没有否认 hibernate 是一个非常优秀的项目,其中所包含的理论水平也的确比 ibatis 高深和先进一些。但是可能有点太过理论化而忽略了一些实际项目中的非常重要的考虑点。
OO 很好,但是也不要到处都用 OO。
我们一定要非常注意避免过度设计。
我是举了一个极端点的例子。比如说有8个字段,其中有一两个比较大的字段,varchar(255)/text。
这个时候我为什么要把这两个大的字段取出来呢?
用 hibernate 的话,你又不能把这两个字段设置为 lazy load,因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出 ibatis 的好处了
http://www.iteye.com/post/48750
这种写法应该是主要为了提高性能的一种手段,感觉不大OO了,本来是一个User对象,现在莫名奇妙的多了UserName,UserAddress等,而这些多出来的对象仅仅是为了能够少查询几个字段.
支持 jamesby 的观点,而且如果采用添加类的方法的话,很快系统里的类就泛滥成灾了。
就拿用户库做例子,可能会有以下可能
1. 取 id, name
2. 取 id, name, password_checksum
3, 取 id, name, 注册日期
等等等等
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
Hibernate也可以只取部分字段的,如“SELECT new UserName(c.userName) FROM customer c”,自己写一个普通JavaBean的UserName类,其中包括 new UserName(String name)的构造方法就可以了。这样也比较OO些
在User里加一个构造函数也就行了。
public User(String name){
}
这种写法应该是主要为了提高性能的一种手段,感觉不大OO了,本来是一个User对象,现在莫名奇妙的多了UserName,UserAddress等,而这些多出来的对象仅仅是为了能够少查询几个字段.
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
Hibernate也可以只取部分字段的,如“SELECT new UserName(c.userName) FROM customer c”,自己写一个普通JavaBean的UserName类,其中包括 new UserName(String name)的构造方法就可以了。这样也比较OO些
在User里加一个构造函数也就行了。
public User(String name){
}
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
Hibernate也可以只取部分字段的,如“SELECT new UserName(c.userName) FROM customer c”,自己写一个普通JavaBean的UserName类,其中包括 new UserName(String name)的构造方法就可以了。这样也比较OO些
我是举了一个极端点的例子。比如说有8个字段,其中有一两个比较大的字段,varchar(255)/text。
这个时候我为什么要把这两个大的字段取出来呢?
用 hibernate 的话,你又不能把这两个字段设置为 lazy load,因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出 ibatis 的好处了
当然有了,Domain Object 是最近本的东西。
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
3. iBatis 可以进行细粒度的优化
3.1 比如说我有一个表,我需要更新其中的一个字段,iBatis 很简单,执行一个sql
UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
但是用 Hibernate 的话就比较麻烦了
3.2 我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据
库读很多数据,节省流量
SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
请问你的系统中有没有Domain Model,还是仅仅按照RowSet来做的?你SELECT的时候没有把所有Domain Model的字段取出来
hibernate的效率高于iBATIS?请讲讲理由。
1,自动组装对象
2,简化查询(这一点最提高效率)
3,更少的sql
4,更加面向对象
5,学习hibernate对比学习ibatis来说虽然成本高但是收获更加大,因为学习hibernate学习到的其实是一种orm思想,这一点尤其重要,对一个人的发展来说比较有利(这一点扯大了)。
6,对二级缓存良好的支持
7,使多数据库版本的规模不大的产品的实现更加容易
非常感谢有几位对 hibernate 有深入了解的朋友给出了我这里提出的问题的 hibernate 解决方案。我提出这几个问题的初衷不是说 hibernate 无法实现这些功能。而是说他的实现比较不美,呵呵。比如说把一些 sql 嵌入到 java 代码中,我觉得这是非常不好的习惯。
v0.3 - 2007-1-1 21:1:1
我在最初的选型的时候是打算选择 Hibernate 的,在研究的过程中发现了 iBatis,经过
分析比较之后我选择了 iBatis。现在我已经使用 iBatis 完成了一个中小型的项目。这个
项目在性能、可维护性、可扩展性方面都非常令我满意。
在这个过程中我也不断的与使用过或者正在使用 Hibernate 的人进行过探讨。而且我本身
也在不断的跟进 Hibernate 的发展。
最终,我的结论是 iBatis 的选择非常正确,而且越用越喜欢它了。
当然了,我对 Hibernate 的理解还是非常有限的,所以这里的关于 Hibernate 的一些观
点的错误之处希望能够得到 Hibernate 高手的指正。
1. iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。
Hibernate 可能需要 3 倍以上的时间来掌握。
2. iBatis 更容易进行 sql 的 优化。
这个应该大家都有共识了。另外 Hibernate 生成的 sql 也实在是太难看了。鉴
于有的朋友提到了 sql 不太重要。我想在这里强调一下我的经验,一般系统性能
的瓶颈都在数据库上。所以这一点是 iBatis 非常重要的一个优势。
3. iBatis 可以进行细粒度的优化
3.1 比如说我有一个表,这个表有几个或者几十个字段,我需要更新其中
的一个字段,iBatis 很简单,执行一个sql
UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
但是用 Hibernate 的话就比较麻烦了,缺省的情况下 hibernate 会更新所有字段。
当然我记得 hibernate 有一个选项可以控制只保存修改过的字段,但是我不太确
定这个功能的负面效果。
3.2 我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据
库读很多数据,节省流量
SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
3.2.1 一般情况下
Hibernate 会把所有的字段都选出来。比如说有一个上面表有8个字段,
其中有一两个比较大的字段,varchar(255)/text。上面的场景中我为什么要把他
们也选出来呢?
3.2.2 用 hibernate 的话,你又不能把这两个不需要的字段设置为 lazy load,因
为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出
ibatis 的好处了
3.2.3 Hibernate 还有一个方案,就是生成 javabean/map/object[](感谢
leelun/cjmm),但是这样的话就可能会产生大量的多余 class。map/object[] 的方式
应该不错,我比较喜欢这种方式。
3.3 如果我需要更新一条记录(一个对象),如果使用 hibernate,需要现把对
象 select 出来,然后再做 update。这对数据库来说就是两条 sql。而 iBatis
只需要一条 update 的 sql 就可以了。减少一次与数据库的交互,对于性能的
提升是非常重要。
4. 开发方面
4.1 开发效率上,我觉得两者应该差不多
4.2 可维护性方面,我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到
单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保存
sql/hql。
5. 运行效率
5.1 在不考虑 cache 的情况下,iBatis 应该会比hibernate 快一些或者很多
(根据实际情况会有所不同)。
当然 iBatis 也有比较大的缺点
1. 不同数据库类型的支持不好,如果你要开发的系统是要在对中数据间移植,那可能用 hibernate 比较好。
2. 缺省的 cache 支持不好,但是 hibernate 的 cache 支持其实也不是很好,而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理 cache。
非常感谢这么多朋友对这个话题很感兴趣。但是我感觉大家并没有对我第三部分提到的问题进行更深入的思考。我晚些时候会提交一些 ibatis 的代码。欢迎大家一起来讨论。
评论
29 楼
iceant
2007-01-01
我不喜欢Hibernate,也不喜欢所谓的OO,大家可以冷静的想想,有多少系统是真正使用的 OO 方式来设计和实现的呢?
OO只是一种思考方式,它可以有助于开发人员了解和分析系统,抽象出系统中的各种元素。但是真正实现,还是要使用传统的各种方法与技术。OO不能解决你所有的问题,言必谈OO,不一定真正的了解OO.
我说个简单点的,有谁能用纯OO实现一个系统,然后又能很好的控制事务的?
Hibernate 也是一样,它也有自己适用的范围和区间。Hibernate 要应用得好,真的是要花很多的时间,我是从JDBC开始写应用的,所以我不喜欢Hibernate,因为它在实现系统时的思维方式与我的不一样~ 我使用 RDBMS 做为 Storage,Hibernate 将 RDBMS 中的 Table 转换为 POJO,在做系统时,我要不停的在 RDBMS Model 和 POJO 之间转换,为的是了解系统底层发生了什么,系统是否能进一步优化,为了能更好的让 Hibernate 发挥效率,我要试很多不同的方式,最终才能确定哪一种在这个情况下可能更合适~ 说句实话,累啊~ 感觉就像是在计算机里不停的切换两个线程~
iBatis简单,最重要的是,我的模型是用 RDBMS 描述的,我能继续用 RDBMS 的方式来处理数据,对于我这种人来说,存贮过程在很多情况下仍然是最好的选择。也许有人会说,你们把业务放在存贮过程中,可扩展性很差。呵~ 所以这就要看你应用的 scope 了,如果性能很重要,使用存贮过程还是很好的选择。而且对我们的应用,除了 Oracle,不可能用别的数据库。
我觉得很多人把精力花在系统的可扩展性和可移植性上了,就我接触过的系统来说,这方面的需求还是很少的。一来有些系统的生命周期非常短,没有必要;再来,系统运行的时间长了,对它进行替换的成本是很高的。
因此我偏向于对一个具体的应用,采取最有效最简单的方式来完成。就像如果需求只是要打印 123,那就 System.out.println("123”)就好了,不要再来个 System.out.println(124-1)
Hibernate 对于熟悉它的人,是一样非常好的工具,Hibernate 的作者也说过,只要是 Hibernate Team 的人,做出来的系统肯定性能不会差~ 但是不熟悉的人就很难说了~ 我建议使用它的人还是读读它的代码,别盲目使用。很难相象一个程序员,对它的工具做了什么都不知道,还能用好它。
Hibernate 还有一样我最不能接受的,就是它的作者。他根本不能接受别人的意见,只想听奉承。对于别人提出的意见示而不见。最有名的就是在 web 系统里 redeploy 时, Hibernate 会因为内存不能得到释放,引起 web 容器down掉(OutofMemoryExcepiton)。很多人都报告过这个问题,但是开发团队从来不承认这是 Hibernate 引起的。一下说是 commons-log.jar的问题,一下又说是 dom4j的问题,一下又说是 tomcat 的问题(已经证实jboss/weblogic/websphere也会出这问题),一下又说是cglib的问题,呵~ 反正理由多得是~ 就是不关 Hibernate 的问题~ 有人在 JIRA 里开了个BUG,被作者以 Session没有 close 为由给close了,他连测都没测一下~ 我经过测试,证明就算是调用了Session.close还是一样会出现这个问题,只要把Hibernate.jar去掉,一切就可以很好的工作。 Hibernate 的论坛上本来有一个贴子就是说这个问题的,很多人都关注过,但是后来不知道为什么这个贴子不在了。这个问题存在很久了,到最新版的Hibernate也没有解决。我很难理解,JBoss为什么要把它引入到 AS 里面去,它就不怕 Hibernate 引起 redeploy 失效吗?这和JBoss AS的 7*24 不相符啊~
最后我想说,在没有ORM的时候,我们一样能做出系统,而且性能也不差,系统一样可以维护,为什么一定要用ORM?有个朋友说,这些技术只是让程序员舒服了,但是软件不见得就强壮多少。我想这句话很有道理。
OO只是一种思考方式,它可以有助于开发人员了解和分析系统,抽象出系统中的各种元素。但是真正实现,还是要使用传统的各种方法与技术。OO不能解决你所有的问题,言必谈OO,不一定真正的了解OO.
我说个简单点的,有谁能用纯OO实现一个系统,然后又能很好的控制事务的?
Hibernate 也是一样,它也有自己适用的范围和区间。Hibernate 要应用得好,真的是要花很多的时间,我是从JDBC开始写应用的,所以我不喜欢Hibernate,因为它在实现系统时的思维方式与我的不一样~ 我使用 RDBMS 做为 Storage,Hibernate 将 RDBMS 中的 Table 转换为 POJO,在做系统时,我要不停的在 RDBMS Model 和 POJO 之间转换,为的是了解系统底层发生了什么,系统是否能进一步优化,为了能更好的让 Hibernate 发挥效率,我要试很多不同的方式,最终才能确定哪一种在这个情况下可能更合适~ 说句实话,累啊~ 感觉就像是在计算机里不停的切换两个线程~
iBatis简单,最重要的是,我的模型是用 RDBMS 描述的,我能继续用 RDBMS 的方式来处理数据,对于我这种人来说,存贮过程在很多情况下仍然是最好的选择。也许有人会说,你们把业务放在存贮过程中,可扩展性很差。呵~ 所以这就要看你应用的 scope 了,如果性能很重要,使用存贮过程还是很好的选择。而且对我们的应用,除了 Oracle,不可能用别的数据库。
我觉得很多人把精力花在系统的可扩展性和可移植性上了,就我接触过的系统来说,这方面的需求还是很少的。一来有些系统的生命周期非常短,没有必要;再来,系统运行的时间长了,对它进行替换的成本是很高的。
因此我偏向于对一个具体的应用,采取最有效最简单的方式来完成。就像如果需求只是要打印 123,那就 System.out.println("123”)就好了,不要再来个 System.out.println(124-1)
Hibernate 对于熟悉它的人,是一样非常好的工具,Hibernate 的作者也说过,只要是 Hibernate Team 的人,做出来的系统肯定性能不会差~ 但是不熟悉的人就很难说了~ 我建议使用它的人还是读读它的代码,别盲目使用。很难相象一个程序员,对它的工具做了什么都不知道,还能用好它。
Hibernate 还有一样我最不能接受的,就是它的作者。他根本不能接受别人的意见,只想听奉承。对于别人提出的意见示而不见。最有名的就是在 web 系统里 redeploy 时, Hibernate 会因为内存不能得到释放,引起 web 容器down掉(OutofMemoryExcepiton)。很多人都报告过这个问题,但是开发团队从来不承认这是 Hibernate 引起的。一下说是 commons-log.jar的问题,一下又说是 dom4j的问题,一下又说是 tomcat 的问题(已经证实jboss/weblogic/websphere也会出这问题),一下又说是cglib的问题,呵~ 反正理由多得是~ 就是不关 Hibernate 的问题~ 有人在 JIRA 里开了个BUG,被作者以 Session没有 close 为由给close了,他连测都没测一下~ 我经过测试,证明就算是调用了Session.close还是一样会出现这个问题,只要把Hibernate.jar去掉,一切就可以很好的工作。 Hibernate 的论坛上本来有一个贴子就是说这个问题的,很多人都关注过,但是后来不知道为什么这个贴子不在了。这个问题存在很久了,到最新版的Hibernate也没有解决。我很难理解,JBoss为什么要把它引入到 AS 里面去,它就不怕 Hibernate 引起 redeploy 失效吗?这和JBoss AS的 7*24 不相符啊~
最后我想说,在没有ORM的时候,我们一样能做出系统,而且性能也不差,系统一样可以维护,为什么一定要用ORM?有个朋友说,这些技术只是让程序员舒服了,但是软件不见得就强壮多少。我想这句话很有道理。
28 楼
downpour
2007-01-01
jiming 写道
引用
觉得楼主这种标题太有煽动性了,其实楼主之所以不选hibernate是因为楼主并不怎么熟悉hibernate而已,楼主应该对jdbc比较熟,而对orm并不熟悉,所以才有此言论,有点片面
千万别把煽动这个大帽子给我口到头上来,赫赫。
其实我对 Hibernate 也进行了相当多的研究。而且应该比很多现在在用 Hibernate 的人要强一些,当然不包括一些大牛门了。
我之所以这么提在我的文章里分析已经很清楚了。我没有否认 hibernate 是一个非常优秀的项目,其中所包含的理论水平也的确比 ibatis 高深和先进一些。但是可能有点太过理论化而忽略了一些实际项目中的非常重要的考虑点。
OO 很好,但是也不要到处都用 OO。
我们一定要非常注意避免过度设计。
从你的分析来看,我觉得你可以稍微花点时间在如何解决你所分析出来的问题上面。你所提到的问题都是可以解决的。
ORM框架各有各的好处,不用过分强调谁行谁不行。老实说,iBatis在做持久化的笨拙就令人受不了。一张表有30个字段,你用ibatis去做一次insert试试?不过在查询方面,iBatis的确有很多优势的地方。
27 楼
smilelee74
2007-01-01
hb也可以只查询几个字段。出来的结果无非就跟JDBC一样是一个list数组。
HB也支持SQL查询。
如果用SPRING,也有JdbcTemplate可以混合用。
用HB维护数据,new 一个OBJECT,然后BeanUtils.copyProperty一下,再SAVE就OK,多清爽。
HB的灵活性可以用nativeSql或则JdbcTemplate来补充,一点不耽误。
HB也支持SQL查询。
如果用SPRING,也有JdbcTemplate可以混合用。
用HB维护数据,new 一个OBJECT,然后BeanUtils.copyProperty一下,再SAVE就OK,多清爽。
HB的灵活性可以用nativeSql或则JdbcTemplate来补充,一点不耽误。
26 楼
宏基小键盘
2006-12-31
iBATIS中的data cache 和 lazy loading也还是不错的,而且2.3.0中增加了prepare statement缓存的支持,记住要开启这个选项。
25 楼
jiming
2006-12-31
引用
觉得楼主这种标题太有煽动性了,其实楼主之所以不选hibernate是因为楼主并不怎么熟悉hibernate而已,楼主应该对jdbc比较熟,而对orm并不熟悉,所以才有此言论,有点片面
千万别把煽动这个大帽子给我口到头上来,赫赫。
其实我对 Hibernate 也进行了相当多的研究。而且应该比很多现在在用 Hibernate 的人要强一些,当然不包括一些大牛门了。
我之所以这么提在我的文章里分析已经很清楚了。我没有否认 hibernate 是一个非常优秀的项目,其中所包含的理论水平也的确比 ibatis 高深和先进一些。但是可能有点太过理论化而忽略了一些实际项目中的非常重要的考虑点。
OO 很好,但是也不要到处都用 OO。
我们一定要非常注意避免过度设计。
24 楼
YuLimin
2006-12-31
从长远的角度出发,应当选择Hibernate,这样无论从系统的开发速度还是后期的维护等等上面来看,都是值得的!虽然要掌握Hibernate是要花高于其它的代价,但是物有所值。
23 楼
ahuaxuan
2006-12-31
觉得楼主这种标题太有煽动性了,其实楼主之所以不选hibernate是因为楼主并不怎么熟悉hibernate而已,楼主应该对jdbc比较熟,而对orm并不熟悉,所以才有此言论,有点片面
22 楼
Sam1860
2006-12-31
前面有个朋友评论得对,这只是一个JDBC高手的观点,而不是所谓ibatis比起hib的优点。
楼主所说的ibatis优点HIB也有,像第3点,HIB做得更好,因为hib的dynamic update根本不用自己操心这种东西
楼主所说的ibatis优点HIB也有,像第3点,HIB做得更好,因为hib的dynamic update根本不用自己操心这种东西
21 楼
daquan198163
2006-12-31
jiming 写道
引用
如果表里有几十个字段,那么大部分时候应该重构一下数据库……我觉得以可能把Domain Model当Value Object用了…
我是举了一个极端点的例子。比如说有8个字段,其中有一两个比较大的字段,varchar(255)/text。
这个时候我为什么要把这两个大的字段取出来呢?
用 hibernate 的话,你又不能把这两个字段设置为 lazy load,因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出 ibatis 的好处了
http://www.iteye.com/post/48750
20 楼
jiming
2006-12-31
引用
这种写法应该是主要为了提高性能的一种手段,感觉不大OO了,本来是一个User对象,现在莫名奇妙的多了UserName,UserAddress等,而这些多出来的对象仅仅是为了能够少查询几个字段.
支持 jamesby 的观点,而且如果采用添加类的方法的话,很快系统里的类就泛滥成灾了。
就拿用户库做例子,可能会有以下可能
1. 取 id, name
2. 取 id, name, password_checksum
3, 取 id, name, 注册日期
等等等等
19 楼
jamesby
2006-12-31
together 写道
leelun 写道
jiming 写道
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
Hibernate也可以只取部分字段的,如“SELECT new UserName(c.userName) FROM customer c”,自己写一个普通JavaBean的UserName类,其中包括 new UserName(String name)的构造方法就可以了。这样也比较OO些
在User里加一个构造函数也就行了。
public User(String name){
}
这种写法应该是主要为了提高性能的一种手段,感觉不大OO了,本来是一个User对象,现在莫名奇妙的多了UserName,UserAddress等,而这些多出来的对象仅仅是为了能够少查询几个字段.
18 楼
together
2006-12-31
leelun 写道
jiming 写道
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
Hibernate也可以只取部分字段的,如“SELECT new UserName(c.userName) FROM customer c”,自己写一个普通JavaBean的UserName类,其中包括 new UserName(String name)的构造方法就可以了。这样也比较OO些
在User里加一个构造函数也就行了。
public User(String name){
}
17 楼
leelun
2006-12-31
jiming 写道
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
Hibernate也可以只取部分字段的,如“SELECT new UserName(c.userName) FROM customer c”,自己写一个普通JavaBean的UserName类,其中包括 new UserName(String name)的构造方法就可以了。这样也比较OO些
16 楼
jiming
2006-12-31
引用
如果表里有几十个字段,那么大部分时候应该重构一下数据库……我觉得以可能把Domain Model当Value Object用了…
我是举了一个极端点的例子。比如说有8个字段,其中有一两个比较大的字段,varchar(255)/text。
这个时候我为什么要把这两个大的字段取出来呢?
用 hibernate 的话,你又不能把这两个字段设置为 lazy load,因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出 ibatis 的好处了
15 楼
刑天战士
2006-12-31
如果表里有几十个字段,那么大部分时候应该重构一下数据库……我觉得以可能把Domain Model当Value Object用了……
14 楼
jiming
2006-12-31
引用
请问你的系统中有没有Domain Model,还是仅仅按照RowSet来做的?你SELECT的时候没有把所有Domain Model的字段取出来
当然有了,Domain Object 是最近本的东西。
但是有的时候,比如说我只需要列出用户名的列表,而用户这个表有很多字段(几十个?),这个时候,我提到的 3.2 的方式就非常棒了。
13 楼
together
2006-12-31
简而言之,如果项目团队不习惯OO,还是老实地用jdbc或者ibatis。
学习HB虽然会痛苦一些,但是所得也多。有多少付出就有多少收获。
学习HB虽然会痛苦一些,但是所得也多。有多少付出就有多少收获。
12 楼
刑天战士
2006-12-31
jiming 写道
3. iBatis 可以进行细粒度的优化
3.1 比如说我有一个表,我需要更新其中的一个字段,iBatis 很简单,执行一个sql
UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
但是用 Hibernate 的话就比较麻烦了
3.2 我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据
库读很多数据,节省流量
SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
请问你的系统中有没有Domain Model,还是仅仅按照RowSet来做的?你SELECT的时候没有把所有Domain Model的字段取出来
11 楼
ahuaxuan
2006-12-31
flyspider 写道
ahuaxuan 写道
我觉得楼主应该没有用过hibernate吧,lz并没有写hibernate的优点,而是一个劲的写缺点,ibatis和hibernate其实应该可以看成是互不的两个东西,hibernate学习成本高于ibatis,但是hibernate的效率也高于ibatis,用hibernate也更oo,我看到lz说ibatis更容易优化芸芸,其实一般的系统要优化的sql语句有多少??一般的项目用hibernate是没有问题的,遗留系统或者性能要求非常苛刻的系统应该用ibatis,这两者没有绝对的好和坏的问题,只有不同的系统不同的项目用哪个更合适的问题,如果lz说hibernate不适合你们的系统,那请讲讲理由好吗
hibernate的效率高于iBATIS?请讲讲理由。
1,自动组装对象
2,简化查询(这一点最提高效率)
3,更少的sql
4,更加面向对象
5,学习hibernate对比学习ibatis来说虽然成本高但是收获更加大,因为学习hibernate学习到的其实是一种orm思想,这一点尤其重要,对一个人的发展来说比较有利(这一点扯大了)。
6,对二级缓存良好的支持
7,使多数据库版本的规模不大的产品的实现更加容易
10 楼
axiang_2898
2006-12-31
iBATIS对于短期项目来说的话好点,如果对于长期项目来说还是用Hibernate来做比较好,呵呵,个人看法,只是一点最表面的!
发表评论
-
Gradle 是个好东西
2014-04-10 10:16 964用来替代 maven 不错 -
Maven eclipse 链接外部资源
2012-02-20 05:41 1757有的时候开发项目的过程中需要编辑一些资源,但是这些资源又不是跟 ... -
获得 jQuery version
2011-02-08 21:46 1069jQuery.fn.jquery -
找了个现在好用的网络硬盘
2011-01-29 23:04 1112最近需要给别人在公网上共享一个比较大的文件,超过 200 兆。 ... -
对 Flex 不看好的一些原因
2010-10-25 16:03 970UI 很漂亮,但是比较难以定制。尤其是在像 jQuer ... -
google 的 Closure Templates 不错
2010-09-17 14:00 1258可以支持 java 和 javascript。 在前端性能 ... -
Introspector.getBeanInfo 对于 generic 支持的 bug
2008-12-19 16:06 1689尽量让 set/get 方法放在同一个 interface ... -
给纯 JSP/JAVABEAN 方案平个反
2008-11-15 22:02 1300最近这几年 JAVA web 开发就像是个可怜的靶子,都快要被 ... -
java memcached lib 性能测试
2008-09-17 21:24 1559这两天有时间,研究了一下最近火的发烫的 memcached. ... -
[转贴]八大优势能否助JSF统一Web开发
2007-02-15 15:42 2501作者:Simon 来源:IT ... -
Re: 讨论一下 cache 应该放在 service 层还是 dao 层吧
2007-02-08 15:54 2594Cache 这个东西,看似简单,但是具体实施起来却是很麻烦,有 ... -
讨论一下 cache 应该放在 service 层还是 dao 层吧
2007-02-07 18:44 13281我个人倾向于放在 service 层。 因为虽然 hiber ... -
发现一个非常优秀的 JSF 包,icefaces
2007-02-06 18:22 4318http://www.icefaces.org/ 效果相当漂 ...
相关推荐
Struts2、Hibernate、Spring 和 iBatis 是四个在Java Web开发中广泛应用的开源框架,它们的整合常常被称为SSH(Struts2、Spring、Hibernate)或者SHiP(Struts2、Hibernate、iBatis、Spring)。这个"struts2+...
在现代企业级应用开发中,iBatis2和Spring框架的结合使用已经成为一种常见的技术选型。iBatis作为一个优秀的SQL映射框架,使得数据库操作更为灵活,而Spring作为全方位的应用框架,提供了依赖注入、事务管理等核心...
SSH(Spring、Struts、Hibernate)是一种经典的Java Web应用程序开发框架,其中Hibernate是一个强大的持久层框架,专注于简化数据库交互。这篇PPT主要介绍了Hibernate的核心概念、持久层的重要性以及ORM(对象关系...
Struts2、Spring和iBatis是Java Web开发中常用的三大框架,它们分别负责MVC模式中的...在实际开发中,根据项目的具体需求,可能还需要考虑其他组件的集成,如Hibernate、MyBatis3等,以达到最佳的技术选型和性能优化。
书首先分析了java web应用的分层设计方法,并进行应用框架的选型,然后讲解各种java web应用框架、集成技术、实战开发。主要内容包括如下。. 持久层框架hibernate:讲解hibernate入门与核心技术,分别实现mysql、...
书首先分析了java web应用的分层设计方法,并进行应用框架的选型,然后讲解各种java web应用框架、集成技术、实战开发。主要内容包括如下。. 持久层框架hibernate:讲解hibernate入门与核心技术,分别实现mysql、...
书首先分析了java web应用的分层设计方法,并进行应用框架的选型,然后讲解各种java web应用框架、集成技术、实战开发。主要内容包括如下。. 持久层框架hibernate:讲解hibernate入门与核心技术,分别实现mysql、...
表现层框架Struts 1:讲解Struts 1的入门配置、核心组件、标签库、国际化、数据校验、Sitemesh集成、数据库开发技术,并分别实现与Hibernate、iBATIS持久层框架的集成开发。..表现层框架Struts 2:讲解Struts 2的...
- **iBATIS**(MyBatis):与 Hibernate 相比,iBATIS 更侧重于 SQL 映射,开发者需要手动编写 SQL 语句,并通过框架提供的工具将其映射到 Java 对象上。这种方式更灵活,但在复杂查询方面可能需要更多手工工作。 ...
J2EE服务端开发涉及的库包括apache-commons提供基础类扩展,json-lib处理JSON数据,junit进行单元测试,struts2/spring mvc作为MVC框架,ibatis/mybatis/hibernate作为ORM层选择。 **选型** 3.1 **中间件**:商业...
此外,对于Hibernate和IBatis的SQL语句以及Spring的Service注入,都要求加上模块名,以防止命名冲突和加载错误。 最后,模块划分的意义在于提升系统的扩展性和可维护性。各模块之间尽量避免直接调用,以降低耦合,...
《大数据功能模块概要设计》是对大数据系统的架构和组件进行详细描述的一份文档,主要涵盖了系统总体架构、通用组件和基础类库的选择,以及中间件和数据库的选型。以下是根据文档内容提炼的关键知识点: 1. **系统...
而对于需要复杂对象关系映射的场景,则Hibernate或iBatis(MyBatis)可能是更好的选择。 #### 结语 《通向架构师的道路》不仅是技术探索的旅程,更是个人成长与家庭责任交织的故事。通过深入理解和运用Spring框架...
数据持久层则涉及数据的存储和访问,包括JDBC、ORMapping工具(如Hibernate、TopLink)、SQLMapper(如iBatis)、JDO以及EJB实体bean等。ORMapping工具简化了对象与数据库之间的映射,提高了开发效率,而JDBC则更为...
- **J2EE基础类库**:如Apache Commons、JSON-Lib用于JSON处理,JUnit进行单元测试,Struts2或Spring MVC作为MVC框架,Spring处理业务逻辑,ORM层可以选择ibatis、mybatis或hibernate。 - **中间件**:商业中间件...
- 随后,开发者会接触到诸如dom4j、jdom、log4j、Hibernate、Spring、iBatis、Struts等开源框架。 - 数据交换中,JSON和XML的封装和解析是必备技能,正则表达式也在开发中扮演重要角色。 - 开发环境如Tomcat、...
- 使用Spring和Alibaba Service框架,引入Velocity模板,使用分布式缓存,数据库访问层开始使用Hibernate和iBatis,以iBatis为主。 3. **每个阶段的技术演进** - **史前到石器时代**:从脚本语言到Java的转变,...
例如,Amoeba用于MySQL,PL/Proxy用于PostgreSQL,而Hibernate Shard、Ibatis Shard和Pyshards则是不同编程语言中的Sharding库。 总的来说,网站架构设计是一个复杂而深奥的领域,涉及到技术选型、系统设计、性能...