Why(not) iBatis?

首先让我们从iBatis的定位开始说起, ‘sql mapping’。
什么是‘sql mapping’？如果这里的‘mapping’也是映射的意思,
那么‘sql mapping’ 是‘sql 到‘sql’，还是‘sql’到‘object'的映射？
如果说是‘sql 到‘sql’的映射，好像说不通，
如果说是‘sql’到‘object'的映射，那么其它任何一个ORM（hibernate， jdo...）都可以说是’sql mapping‘了。
为什么这么说？因为任何ORM产品最终都要把用户输入参数转换成sql语句，然后执行，取结果转换’object‘
不同的是iBatis是直接把’sql‘语句写在xml文件里，
如果有工具（如UI）可以根据你输入或设置自动生成iBatis的xml文件，我想那时iBatis仍叫’sql mapping‘，不会说成’UI mapping‘吧。

这样一来，我想我们就可以把jdbc，iBatis或其它的ORM（hibernate）产品从功能尺度去比较衡量。

jdbc最基本，执行用户写的sql语句，取出来的结果是ResultSet，

iBatis也执行用户写的sql语句，
至于他把sql语句是写在xml文件，我认为这不是它的特点,
任何一个jdbc（或直接执行sql语句）的程序你都可以把sql语句写到一个xml文件去。
我认为它与jdbc的不同在于它把结果集ResultSet转换成了Object，另外提供过任何一个持久方案都提供的一些功能集，如连接池，缓存等。
我认为这jdbc是一种进化。

其它的ORM产品（象hibernate，jdo），
则是根据用户的输入参数，可能是某种形式的sql语句或其它的结构（如果hibernate的Criteria）或配置来生产最终需要执行的sql语句，
它们与iBatis一样也把结果集转换成了Object，另外提供一些功能集，如连接池，缓存等。
至于它们把结果集ResultSet转换成object的方法或支持的能度，就不仔细分辨了。
我想这是对iBatis算一种进化吧。

上面是从用户的角度吧iBatis与jdbc和ORM作了一个简单的比较。
我再回到iBatis的本身来分析它的特点。
1，它是把sql语句写在xml文件了，不想一般jdbc习惯把sql语句写在代码里。
2，sql语句是有用户自己写的（借用一下POJO）plain old sql语句。
3，它直接执行用户写的plain old sql语句。
4，它把结果集转换成了object。
5，它提供连接池，缓存等功能。
6，它容易学。
(如其它特性的疏忽，请见谅和指出，谢谢！）

下面我们来一条条分析。
1，把sql语句写xml文件里有什么好呢？
用个例子，我们写代码有个code rule就是把concrete字符串提出来写成一个变量或写成常量表（可以是class或property文件等）。
这样做有什么好？
a）便于阅读，如果你把这项变量聚在一起，很容由此及彼，
但如果你把这些字符串插在代码里，这里一个，那里一个，对你写代码的人说可能没什么，但对其它review或维护你代码的人就不容易，
如果你字符串很长，你把写一个能表达意思的变量，可阅读就大提高了...
b）便于维护，如你改名，你可以用’rename‘重构，
   但如果写concrete 字符串，虽然你可用serach－replace，但这不符合规则，容易出错。（如果你习惯于这样做，可能不这么认为）

c）如果写成变量表（如property 文件）还可以改变量明，而不需新编译。
......

那么把sql语句写xml文件有这些好去吗？

2，sql语句是由用户自己写，
这又什么好呢？灵活，可以充分发挥sql的功能。

3，它直接执行用户写的sql语句，
这个呢？性能好，不需任何转换或检查。

4，它把结果集转换成object，
5，它提供连接池，缓存等功能。
4，5就不分析了，通常它们不是人们为什么选择iBatis的原因，虽然少了这些功能人们不会用iBatis。

6，它容易学。
这个从人的本性（这里不说这些本性好与坏），一个第一印象，另一个是惰性，人们通常选择简单的，避开难的。

呵呵，看烦了吧:-)我们再倒过了看，
6， 任何一个好的产品，易学易用都是衡量它的一个不可避免的标准。
    但我们首先要看的是它能否解决我们的问题，一个产品如果不能很好地解决我们的问题，哪怕它是1＋1的简单，
    我们也不好用它，相反，如果一个产品很难，但它能有很好解决我们的问题，我们又不得不用它。

4，5跳过。

3，iBatis在sql语句转换节省下来的时间不是导致我们性能瓶颈的原因，所以它的性能好些没有任何意义，
例如一个程序如果它执行等待的时间超过7（是7？）秒，ibatis执行为我们省小了0.01秒sql转换的时间，这对用户（人）来说是没任意的。

2，灵活，可以充分发挥sql的功能。
   这又是虚无缥缈的，sql语句的灵活和功能强是为了解决不同的环境下的不同的问题。
   如不是为了你随我心写或随我欲强。
   灵活，随从理论上说你可以随意，你现实中你还得中规中矩地写常规sql语句
   可以说在100个sql语句，可能有少于20（安20/80的原则说的，实际肯定少于20）需要发挥你的写灵活或强的sql语句的本领。
   即使你真有这样的本领，还是慎用为好，应首先检查你数据结构或程序的设计。
   如果实在无法避免，那你完全没有必要为了这极少数sql语句而牺牲决大多数sql语句，可以用native sql去做。

   从反面看，直接写sql语句：首先要你懂sql语句，记住数据库表，其次，sql语句难于维护，最后，难于移植，
  
   所以我们应做的避开直接写sql语句，而不是（想）要写sql语句。

   你所应面对的是采用什么方案去解决你的问题，而不是去关注sql的灵活或发挥sql强功能。


1，也许iBatis凑合吧，

:-)完了，需要说明的是,我发表只是自己对iBatis的一些看法。
当然希望它能发展的更好，提过更好的方案解决大家所关注的问题。

在大型系统中，对 SQL 语句的调优还是有非常明显的效果的。即使数据库设计得很好，面对复杂的报表查询，这一步还是不能省去。

数据大了后,俺们都用文件了(xml),xql还能用
索引无限建,数据随便分布.

ｌｚ总结得有点意思

节约开发时间才是关键，简单是他最大的特点，直接导致代码量减少。简单易学这一点跟Hibernate比较，Gavin King自己都说过Hibernate学习曲线较高。


使用DataMapper，只要稍微熟悉JavaBean，XML，SQL就可以很快上手了，基础要求不那么高，从初学者角度看避免了JDBC冗长的操作(相对于不熟悉Spring的JDBC模板的初学者而言)。
将SQL放到代码以外的办法有很多，但最简单的还是放到XML里面，虽然JDBC也可以实现，但你需要写帮助类来解析XML，将这部分代码抽象出来不就又形成了框架了么，这些工作IBatis都帮你做了。

其实我很反对将SQL语句写在XML里面。我曾经这样做过尝试，也使用了ibatis，结果我发现在调试过程中很不容易发现问题。因为一旦系统比较大，XML即使分类做得再好，也避免不了XML文件变得很大。这个时候，由于是多人协作开发，就导致你很难找到相应的代码段。不像是Java中，你可能只要简单的F3，Ctrl+T，就能迅速定位。

另外一个问题就是XML的可读性，iBatis引入了很多很好的处理SQL语句的特性，这简化了我不少工作，但是老实说，写的时候，我的思路还比较清楚，一旦我回过头来再看我写的东西，天哪~~标签套标签，几乎看不见一个完整的SQL表达式了。

所以有的时候我感觉在实战中，还是要根据自己的喜好来进行选择。我现在就比较倾向使用JDBCTemplate，尤其是NamedParameterJdbcTemplate，这个东西接口比较简单，使用和测试都无需很多XML配置文件。

xml文件增大也是问题啊。而且还不利于调试，但是总的说来，还是利大于避的。

我一直想知道iBatis对于关系映射是怎么做的，Hibernate关系映射作的就很好。

ibatis 错误报告也很详细阿
容易定位
不规则的GRUD 用他很灵活省事

可以动态列UPDATE INSERT

如果 hibernate 7S ibatis 6.99s  瓶颈估记也不在他俩身上了


而且性能只看单个请求是没什么意义

数据库，程序在一台机器上 和 数据库，程序分在两个机器上 单个请求能看出什么么