项目总结-简单需细致的东西

     1 iBatis的SQL参数传递注意事项  

      项目的数据库字段设计是另外一同事完成的，我负责写DAO层，发现自己英语太好也是种毛病，今天碰到一个问题是设置SQL的条件查询时，后台传入的Map中使用的key的名称和数据库表字段不一致，导致SQL的参数没有设置进去。仔细检查才发现DAO传入到iBatis的SLQ正常，而SQL拼接参数时的参数名称和传入的不一致。根源是：微信粉丝表的一个字段是微信昵称（表字段是nikeName），我写页面和后台时用的是nickName。当正确的拼写碰到错误的拼写时，bug就发生了。

     2 iBatis的SQL参数拼接#和$的区别

     编写iBatis的Sql时，动态拼接SQL条件时常涉及到精确匹配和模糊匹配，使用精确匹配用col=#var#，模糊匹配则为col like '%$var$%。了解了下#和$的区别，前者是变量替换，涉及到类型匹配，后者是字符串简单拼接。碰到#的类型校验而出错的代码示例：

<!-- 分页查询信息-->
	<select id="queryByPage" resultMap="baseMsgDetail" parameterClass="java.util.Map">
		SELECT 	ID, KEYWORD,MSGTYPE, REPLYTYPE,RESOURCEID, CONTENT, FROM_UNIXTIME(UPDATETIME) as UPDATETIME, 
		FROM_UNIXTIME(CREATETIME) as CREATETIME, STATUS,
		CREATERID, CREATERNAME,  AUDITID, AUDITNAME
		FROM weixin_msg_base where 1=1
		<isNotNull prepend="and" property="id">
			ID=#id#
		</isNotNull>
		order by CREATETIME DESC
		limit #offset#,#limit#
	</select>

上述SQL的入参是Map，分页的参数类型本质上应该是int的数值类型，当我传递Map设置的分页参数offset、limit为String类型时，iBatis的SQL语句拼接则按照字符串拼接成了select * fromweixin_msg_base where 1=1order by CREATETIME DESC limit '0','20',该SQL执行过程中会因为有类型校验遭遇异常。

         总结：使用iBatis编写DAO碰到各种拼写问题，充分说明编程的确是个细致活，也能体会出MyBatis的新特征衍生的过程（各种DAO重复的代码的确可以通过XML配置完成）。复制也是容易出错的，需要在复制完成后仔细检查。