ibatis给我们带来了什么

自从unclepeng commons 2.0发布以后，笔者一直在寻找合适的orm框架，以期加以改造作为unclepeng orm的起源。

很久之前曾经深使用过ibatis，后来由于一直都在维护人家的代码故没有深入下去，趁这几天重新研究了下，却发现当时自己觉得很适用的东西，今日已成鸡肋。

笔者曾经使用过spring的jdbctemplate，后来经过重新实现，直接作为unclepeng commons 2.0的一部分，本文即通过jdbctemplate与ibatis之间的对比，阐述笔者放弃ibatis的原因。

1、有人说ibatis把sql语句放在配置文件里方便管理。这个我不敢苟同，对我来说，文件越多，头越晕，所以这个“优点”不算是优点。

2、代码量的对比，比如查询所有的用户，用ibatis实现如下

public class user {

private int id;
private string name;
private string pwd;

public int getid() {
return id;
}
public void setid(int id) {
this.id = id;
}
public string getname() {
return name;
}
public void setname(string name) {
this.name = name;
}
public string getpwd() {
return pwd;
}
public void setpwd(string pwd) {
this.pwd = pwd;
}
}


public static list selectallaccounts () throws sqlexception {
return sqlmapper.queryforlist("selectall");
}

对应的xml如下

esultmap id="users" class="user">
<result property="id" column="id"/>
<result property="name" column="name"/>
<result property="pwd" column="pwd"/>
</resultmap>

<!-- select with no parameters using the result map for account class. -->
<select id="selectall" resultmap="users">
select * from account
</select>

说白了其实是两部分，一部分是sql参数的填充生成statement，另一部分是将查询结果与object之间的mapping。

用jdbctemplate

string sql = "select * from account";

return template.queryforrowsetlist(sql);

当然这里将所有的查询结果都mapping到rowset这个类里了，如果要mapping到指定的类，需要这样：

public interface rowmapper{

object maprow(resultset rs, int rownum) throws sqlexception;
}

其中user类需要实现rowmapper接口，并指定rs到user字段之间的映射，而这与
<resultmap id="users" class="user">
<result property="id" column="id"/>
<result property="name" column="name"/>
<result property="pwd" column="pwd"/>
</resultmap>
所做的事情是一样的。

所以！从编码量上来看，ibatis与jdcbtemplate 相比不具备优势。

3、性能上的对比，笔者经过测试，忽略cashe，纯粹的数据库操作下，jdbctemplate的性能比ibatis快一倍。

4、ibatis具备cache，更强大？笔者认为作为纯粹的数据库持久操作，cache不应混杂其中.另外，这种使用方式很难适应类似换分布式缓存memcache的需求。正解的做法是把数据库操作跟cache独立分开，cache对数据或对象提供接口，这样切换缓存方案时能够更加平滑。

5、上文中的user类存在的意义仅仅是为了将数据库查询中来的数据mapping其中，为了查询一百多个表，你可能不得不写一百个类似的类，而且对于像数据库添加几个字段的需求响应过慢。倒还不如直接用hashmap来封装字段名与字段值来得干脆，这样还具备了动态的功能。

其实笔者还嫌hashmap过于”重量“，直接用两个数组的映射做为rowset的实现，试想一个表字段总不可能超过1000个，而这种直接用字段名与字段值数组之间建之映射的办法在经过测试之后确实也颇为高效。所以用ibatis灵活性可扩展性都不如jdbctemplate。

6、对于历史性代码，很多都把数据源或者数据库连接字符串直接写入properties中，又或者历史代码都是对connection进行操作，又或者历史代码都是更为丑陋的jdbc实现，用jdbctemplate能够无缝地修改这些代码，对ibatis来说，那是不敢想象的，什么都要实现两套的话，倒不如一套来得好。

既然ibatis不适合笔者，那什么时候适合用ibatis呢？适用于什么人呢？作为半成品的or/mapping框架，ibatis把sql抽取出来作为配置，另外还抽取出了object 与数据库数据之间的mapping配置，让程序员从两个泥沼之中解脱了出来：一、冗长而风格各异的的jdbc查询代码， 二、重复的resultset到object的mapping代码。

相比传统的jdbc确实是一大改进，同时也有利于统一项目组统一持久层的编码风格。如果你对hibernate等更强大的orm没有足够的把控能力，又不想写冗长的jdbc，而且你还没有时间实现自己的jdbctemplate（spring提供的那个还不够好用，需要改造），那么使用ibatis是不二之选。

以上仅代表我个人观点，如与主流思想有冲突，以主流思想为主