mybatis相对于ibatis的优势

2010年，apache的Ibatis框架停止更新，并移交给了google团队，同时更名为MyBatis。从2010年后Ibatis在没更新过，彻底变成了一个孤儿框架。一个没人维护的框架注定被mybatis拍在沙滩上。

1. 入参无需用对象封装（或者map封装）,使用@Param注解

当Ibatis需要接收超过一个参数时，则需要将多个参数封装成对象，这个时候会产生很多Domain查询类。还有很多同学偷懒，写用hashmap传参，这种方式会彻底丧失代码的优雅性，同时hashmap方式很容易造成bug

如果你的映射器的方法需要多个参数, 这个注解可以被应用于映射器的方法参数来给每个参数一个名字。否则,多参数将会以它们的顺序位置来被命名 (不包括任何 RowBounds 参数) 比如。 #{param1} , #{param2} 等 , 这是默认的。使用 @Param(“person”),参数应该被命名为 #{person}。

示例：

    List<BizDO> queryByDomainCodeAndKey(@Param("bizDomainCode") String bizDomainCode,@Param("status") Integer status,@Param("key") String key,@Param("startIndex") Integer startIndex,@Param("pageSize") Integer pageSize);

2. 无需写ResultMap。开启mapUnderscoreToCamelCase配置即可

在ibatis的sql文件中，所有的跟数据库表对应的DataObject类都需要写冗长的映射配置。当数据库表增加了字段时要对这段配置进行同步修改。下划线自动映射到驼峰规则彻底摒弃了这个多余的配置。这个特性同样极大的提高了生产力

是否开启自动驼峰命名规则（camel case）映射，即从经典数据库列名 A_COLUMN 到经典 Java 属性名 aColumn 的类似映射

3. 无需写的DAO层实现类

在Ibatis中，每个sql的xml文件都有一个namespace,而要调用文件中的sql时需要用namespace + sql id 映射到具体的sql。这样代码里徒增很多字符串常量。
Mybatis实现了DAO接口与xml映射文件的绑定，接口的方法名自动映射到sql的id。不再需要代码里拼接sqlid。
实现机制参考我的另外一篇文章 Mybatis只有接口没有实现类的原理

4. 支持Ognl表达式

在Mybatis的If表达式里可以使用Ognl表达式，相对于Ibatis只能使用固定的标签，这个特性太强大了。你可以使用任何第三方框架的方法进行判断。
缺点也在于，Ognl表达式太灵活，不容易驾驭。有几次印象深刻的mybatis的问题，都是ognl表达式造成的，排查了很久。

 <update id="update" parameterType="BizModelDO">UPDATE table_name<set><if test="!@org.springframework.util.StringUtils@isEmpty(modelName)">model_name= #{modelName},</if><if test="!@org.springframework.util.StringUtils@isEmpty(parentCode)">parent_code = #{parentCode},</if><if test="height != null">height = #{height},</if><if test="number != null">number = #{number},</if></set>WHERE model_code = #{modelCode}</update>

5.pagehelper,sorthelper等插件的支持

在Ibatis下，每个分页查询都需要写两条SQL，一条查询sql,还有一条统计总数的sql，两个sql几乎一模一样。
在MyBatis下，配置下pagehelper插件，就只需要写一条查询sql。统计的sql会由pagehelper插件来完成。同样提高了生产效率。
pagehelper github地址

没有理由再选择Ibatis作为ORM框架，拥抱MyBatis吧。