|
锁定老帖子 主题：Why(not) iBatis?
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-03-30
楼主的看法有些偏激了，说简单一点，0.1秒对你而言没用，可以对于我而言提高0.1秒要作为一个项目去做
|
| 返回顶楼 | |
|
发表时间：2007-03-30
yiding_he 写道 在大型系统中，对 SQL 语句的调优还是有非常明显的效果的。即使数据库设计得很好，面对复杂的报表查询，这一步还是不能省去。
同意，不过应该准确的说在性能有问题的时候，调优sql语句可能是很有效的。小的系统，如果有性能问题，也要调优sql语句，但这里有一个80，20的问题。即使在一个大的系统，如果设计好的话，这样的语句数量也是少部分的。如果我们选择ORM，你可以用native sql语句，所以sql语句调优跟你是用iBatis还是其它的ORM产品（只要他支持native sql）是没关系的。 |
| 返回顶楼 | |
|
发表时间：2007-03-30
lgn21st 写道 lihy70 写道 6， 任何一个好的产品，易学易用都是衡量它的一个不可避免的标准。
但我们首先要看的是它能否解决我们的问题，一个产品如果不能很好地解决我们的问题，哪怕它是1＋1的简单， 我们也不好用它，相反，如果一个产品很难，但它能有很好解决我们的问题，我们又不得不用它。 4，5跳过。 3，iBatis在sql语句转换节省下来的时间不是导致我们性能瓶颈的原因，所以它的性能好些没有任何意义， 例如一个程序如果它执行等待的时间超过7（是7？）秒，ibatis执行为我们省小了0.01秒sql转换的时间，这对用户（人）来说是没任意的。 节约开发时间才是关键，简单是他最大的特点，直接导致代码量减少。简单易学这一点跟Hibernate比较，Gavin King自己都说过Hibernate学习曲线较高。 据我的了解（也是听别人讲的），ORM产品（例如hiberante）的开发效率要高些。第二点，易学不等于它的开放效率高；难学，不等于它的开放效率低，是这样的吧？lgn21st (这并不表明我喜欢hibernate，实际它太难了） lgn21st 写道 引用 2，灵活，可以充分发挥sql的功能。
这又是虚无缥缈的，sql语句的灵活和功能强是为了解决不同的环境下的不同的问题。 如不是为了你随我心写或随我欲强。 灵活，随从理论上说你可以随意，你现实中你还得中规中矩地写常规sql语句 可以说在100个sql语句，可能有少于20（安20/80的原则说的，实际肯定少于20）需要发挥你的写灵活或强的sql语句的本领。 即使你真有这样的本领，还是慎用为好，应首先检查你数据结构或程序的设计。 如果实在无法避免，那你完全没有必要为了这极少数sql语句而牺牲决大多数sql语句，可以用native sql去做。 使用DataMapper，只要稍微熟悉JavaBean，XML，SQL就可以很快上手了，基础要求不那么高，从初学者角度看避免了JDBC冗长的操作(相对于不熟悉Spring的JDBC模板的初学者而言)。 将SQL放到代码以外的办法有很多，但最简单的还是放到XML里面，虽然JDBC也可以实现，但你需要写帮助类来解析XML，将这部分代码抽象出来不就又形成了框架了么，这些工作IBatis都帮你做了。 我当然承认ibatis处理xml sql语句是做的很好的，但我想这不是选择一个ORM（方案）理由。可能可以作为一个jdbc方案的理由吧。 |
| 返回顶楼 | |
|
发表时间：2007-03-30
5是ibatis的一个大弱点，因为5不是ibatis的卖点
|
| 返回顶楼 | |
|
发表时间：2007-03-30
jfy3d 写道 引用 3，iBatis在sql语句转换节省下来的时间不是导致我们性能瓶颈的原因，所以它的性能好些没有任何意义，
例如一个程序如果它执行等待的时间超过7（是7？）秒，ibatis执行为我们省小了0.01秒sql转换的时间，这对用户（人）来说是没任意的。 如果 hibernate 7S ibatis 6.99s 瓶颈估记也不在他俩身上了 而且性能只看单个请求是没什么意义 数据库，程序在一台机器上 和 数据库，程序分在两个机器上 单个请求能看出什么么 呵呵，你（可能很多人）都误会了我这句话的意思。我的意思有仅有两点： 1，转sql语句（，从参数或其它的形式）是不需要什么时间的，当我们有性能的问题时，我们不应把归则于转换sql语句。 2，不要担心转换sql语句给我们带来性能问题，可能性能会有点点降，但这不足以引起问题，更不会成问题， 不信你可以测一下。 引用 如果 hibernate 7S ibatis 6.99s 瓶颈估记也不在他俩身上了
如果ibatis 6.99s ，那么hibernate 7S吗？ 我不确定，但我想不是，你不能把hibernate与iBatis在某些性能方面的差异归于sql 语句转换，hibernate还做了很多其它的事。 |
| 返回顶楼 | |
|
发表时间：2007-03-30
lszone 写道 楼主的看法有些偏激了，说简单一点，0.1秒对你而言没用，可以对于我而言提高0.1秒要作为一个项目去做
我说的时0.01，不是0.1 
对不起，我没写清楚让你误会，其实我在这里不是说0.01秒的问题。 举上面那个例子，我是也仅是想说明sql语句不会带来（或构成）性能问题。 不过从另方面我得说，iBatis，很好，没有带来自身的性能问题。 不像hibernate在这方面就有，或这说要让它没有，很困难复杂。 |
| 返回顶楼 | |
|
发表时间：2007-03-30
刑天战士 写道 我一直想知道iBatis对于关系映射是怎么做的，Hibernate关系映射作的就很好。
我们的关系映射也做的很好
http://sourceforge.net/projects/dbcoat |
| 返回顶楼 | |
|
发表时间：2007-03-30
lihy70 写道 刑天战士 写道 我一直想知道iBatis对于关系映射是怎么做的，Hibernate关系映射作的就很好。
我们的关系映射也做的很好
http://sourceforge.net/projects/dbcoat 关系搞来搞去，就是SQL连接而已， ORM也只是在此基础上套了个马甲， 本质还是没变的 |
| 返回顶楼 | |
|
发表时间：2007-03-30
giscat 写道 lihy70 写道 刑天战士 写道 我一直想知道iBatis对于关系映射是怎么做的，Hibernate关系映射作的就很好。
我们的关系映射也做的很好
http://sourceforge.net/projects/dbcoat 关系搞来搞去，就是SQL连接而已， ORM也只是在此基础上套了个马甲， 本质还是没变的  你这话太正确了！对一只乌龟来说，它就是需要一个马甲。
对我们来说，套个马甲，可能意味这更高的效率，更少的加班 |
| 返回顶楼 | |
|
发表时间：2007-03-30
iBATIS 3.0 Whiteboard 摘要
变化非常大,虽然部分还在讨论中,但是iBatis3.0 从提到的特性来看,会有很大不同,尤其是针对java 1.5 作了很多设计 1. Interface Binding 接口绑定(Java5 支持) 2. 事务处理上变得更加灵活 3. Multilevel Configuration Convention Annotation (overrides convention) XML (overrides convention and annotation) Java API (overrides convention, annotation and XML) 4. Dynamic SQL 能够基于代码/annotaion的动态sql 配置 http://opensource.atlassian.com/confluence/oss/display/IBATIS/iBATIS+3.0+Whiteboard |
| 返回顶楼 | |
