Mybatis学习总结之mybatis使用建议
简介：什么是MyBatis？
（前身为iBatis）MyBatis是一个可以自定义SQL、存储过程和高级映射的持久层框架。MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索。MyBatis可以使用简单的XML或注解用于配置和原始映射，将接口和Java的POJO（PlainOldJavaObjects，普通的Java对象）映射成数据库中的记录。
1.Mapper层参数为Map,由Service层负责重载。
Mapper由于机制的问题，不能重载，参数一般设置成Map，但这样会使参数变得模糊，如果想要使代码变得清晰，可以通过service层来实现重载的目的，对外提供的Service层是重载的，但这些重载的Service方法其实是调同一个Mapper，只不过相应的参数并不一致。
也许有人会想，为什么不在Service层也设置成Map呢？我个人是不推荐这么做的，虽然为了方便，我在之前的项目中也大量采用了这种方式，但很明显会给日后的维护工作带来麻烦。因为这么做会使你整个MVC都依赖于Map模型，这个模型其实是很不错的，方便搭框架，但存在一个问题：仅仅看方法签名，你不清楚Map中所拥有的参数个数、类型、每个参数代表的含义。
试想，你只对Service层变更，或者DAO层变更，你需要清楚整个流程中Map传递过来的参数，除非你注释或者文档良好，否则必须把每一层的代码都了解清楚，你才知道传递了哪些参数。针对于简单MVC，那倒也还好，但如果层次复杂之后，代码会变得异常复杂，而且如果我增加一个参数，需要把每一个层的注释都添加上。相对于注释，使用方法签名来保证这种代码可控性会来得更可行一些，因为注释有可能是过时的，但方法签名一般不太可能是陈旧的。
2.尽量少用ifchoose等语句，降低维护的难度。
Mybatis的配置SQL时，尽量少用ifchoose等标签，能用SQL实现判断的尽量用SQL来判断(CASEWHEN,DECODE等)，以便后期维护。否则，一旦SQL膨胀，超级恶心，如果需要调试Mybatis中的SQL，需要去除大量的判断语句，非常麻烦。另一方面，大量的if判断，会使生成的SQL中包含大量的空格，增加网络传输的时间，也不可取。
而且大量的ifchoose语句，不可避免地，每次生成的SQL会不太一致，会导致ORACLE大量的硬解析，也不可取。
我们来看看这样的SQL：
<codeclass="hljssql"style="padding:0.5em;margin:0px;display:block;color:rgb(101,123,131);overflow-x:auto;background:rgb(253,246,227)"><spanclass="hljs-operator"style="padding:0px;margin:0px"><spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SELECT</span>*<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">FROM</span>T_NEWS_TEXT<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">WHERE</span><spanclass="hljs-number"style="padding:0px;margin:0px;color:rgb(42,161,152)">1</span>=<spanclass="hljs-number"style="padding:0px;margin:0px;color:rgb(42,161,152)">1</span>
<<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">choose</span>>
<<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">if</span>test=<spanclass="hljs-string"style="padding:0px;margin:0px;color:rgb(42,161,152)">"startdate!=nullandstartdate!=''andenddate!=nullandendate!=''"</span>>
<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">AND</span>PUBLISHTIME>=#{startdate}<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">AND</span>PUBLISHTIME<=#{enddate}
</<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">if</span>>
<otherwise>
<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">AND</span>PUBLISHTIME>=<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SYSDATE</span>-<spanclass="hljs-number"style="padding:0px;margin:0px;color:rgb(42,161,152)">7</span><spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">AND</span>PUBLISHTIME<=<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SYSDATE</span>
</otherwise></<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">choose</span>></span>
这样的if判断，其实是完全没有必要的,我们可以很简单的采用DECODE来解决默认值问题：
<codeclass="hljssql"style="padding:0.5em;margin:0px;display:block;color:rgb(101,123,131);overflow-x:auto;background:rgb(253,246,227)"><spanclass="hljs-operator"style="padding:0px;margin:0px"><spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SELECT</span>*<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">FROM</span>T_NEWS_TEXT<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">WHERE</span>PUBLISHTIME>=<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">DECODE</span>(#{startdate},<spanclass="hljs-literal"style="padding:0px;margin:0px">NULL</span>,<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SYSDATE</span>-<spanclass="hljs-number"style="padding:0px;margin:0px;color:rgb(42,161,152)">7</span>,#{startdate})<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">AND</span>PUBLISHTIME<=<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">DECODE</span>(#{enddate},<spanclass="hljs-literal"style="padding:0px;margin:0px">NULL</span>,<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SYSDATE</span>,#{enddate})</span></code>
当然有人会想，引入CASEWHEN,DECODE会导致需要ORACLE函数解析，会拖慢SQL执行时间，有兴趣的同学可以回去做一下测试，看看是否会有大的影响。就个人经验而言，在我的开发过程，没有发现因为函数解析导致SQL变慢的情形。影响SQL执行效率的一般情况下是JOIN、ORDERBY、DISTINCT、PARTITATIONBY等这些操作，这些操作一般与表结构设计有很大的关联。相对于这些的效率影响程度，函数解析对于SQL执行速度影响应该是可以忽略不计的。
另外一点，对于一些默认值的赋值，像上面那条SQL，默认成当前日期什么的，其实可以完全提到Service层或Controller层做处理，在Mybatis中应该要少用这些判断。因为，这样的话，很难做缓存处理。如果startdate为空，在SQL上使用动态的SYSDATE，就无法确定缓存startdate日期的key应该是什么了。所以参数最好在传递至Mybatis之前都处理好，这样Mybatis层也能减少部分ifchoose语句，同时也方便做缓存处理。
当然不使用ifchoose也并不是绝对的，有时候为了优化SQL，不得不使用if来解决，比如说LIKE语句，当然一般不推荐使用LIKE，但如果存在使用的场景，尽可能在不需要使用时候去除LIKE，比如查询文章标题，以提高查询效率。最好的方式是使用lucence等搜索引擎来解决这种全文索引的问题。
总的来说，if与choose判断分支是不可能完全去除的，但是推荐使用SQL原生的方式来解决一些动态问题，而不应该完全依赖Mybatis来完成动态分支的判断，因为判断分支过于复杂，而且难以维护。
3.用XML注释取代SQL注释。
Mybatis中原SQL的注释尽量不要保留，注释会引发一些问题，如果需要使用注释，可以在XML中用<!---->来注释，保证在生成的SQL中不会存在SQL注释，从而降低问题出现的可能性。这样做还有一个好处，就是在IDE中可以很清楚的区分注释与SQL。
现在来谈谈注释引发的问题，我做的一个项目中，分页组件是基于Mybatis的，它会在你写的SQL脚本外面再套一层SELECTCOUNT(*)ROWNUM_FROM(....)计算总记录数，同时有另一个嵌套SELECT*FROM(...)WHEREROWNUM>10ANDRONNUM<10*2这种方式生成分页信息，如果你的脚本中最后一行出现了注释，则添加的部分会成为注释的一部分，执行就会报错。除此之外，某些情况下也可能导致部分条件被忽略，如下面的情况：
<codeclass="hljsvbnet"style="padding:0.5em;margin:0px;display:block;color:rgb(101,123,131);overflow-x:auto;background:rgb(253,246,227)"><spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">SELECT</span>*<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">FROM</span>TEST<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">WHERE</span>COL1><spanclass="hljs-number"style="padding:0px;margin:0px;color:rgb(42,161,152)">1</span>--这里是注释<<spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">if</span>test=<spanclass="hljs-string"style="padding:0px;margin:0px;color:rgb(42,161,152)">"a!=nullanda!=''"</span>><spanclass="hljs-keyword"style="padding:0px;margin:0px;color:rgb(133,153,0)">AND</span>COL2=<spanclass="hljs-preprocessor"style="padding:0px;margin:0px;color:rgb(203,75,22)">#{a}</<spanclass="hljs-keyword"style="padding:0px;margin:0px">if</span>></span></code>
即使传入的参数中存在对应的参数，实际也不会产生效果，因为后面的内容实际上是被完全注释了。这种错误，如果不经过严格的测试，是很难发现的。一般情况下，XML注释完全可以替代SQL注释，因此这种行为应该可以禁止掉。
4.尽可能使用#{}，而不是${}.
Mybatis中尽量不要使用${}，尽量这样做很方便开发，但是有一个问题，就是大量使用会导致ORACLE的硬解析，拖慢数据库性能，运行越久，数据库性能会越差。对于一般多个字符串IN的处理，可以参考如下的解决方案:http://www.myexception.cn/sql/849573.html，基本可以解决大部分${}.
关于${}，另一个误用的地方就是LIKE，我这边还有个案例：比如一些树型菜单，节点会设计成'01','0101',用两位节点来区分层级，这时候，如果需要查询01节点下所有的节点，最简单的SQL便是:SELECT*FROMTREEWHEREIDLIKE'01%',这种SQL其实无可厚非，因为它也能用到索引，所以不需要特别的处理，直接使用就行了。但如果是文章标题，则需要额外注意了：SELECT*FROMT_NEWS_TEXTWHERETITLELIKE'%OSC%'，这是怎么也不会用到索引的，上面说了，最好采用全文检索。但如果离不开LIKE，就需要注意使用的方式：IDLIKE#{ID}||'%'而不是IDLIKE'${ID}%'，减少硬解析的可能。
有人觉得使用||会增加ORACLE处理的时间，我觉得不要把ORACLE看得太傻，虽然有时候确实非常傻，有空可以再总结ORACLE傻不垃圾的地方，但是稍加测试便知：这种串联方式，对于整个SQL的解析执行，应该是微乎其微的。
当然还有一些特殊情况是没有办法处理的，比如说动态注入列名、表名等。对于这些情况，则比较棘手，没有找到比较方便的手段。由于这种情况出现的可能性会比较少，所以使用${}倒也不至于有什么太大的影响。当然你如果有代码洁癖的话，可以使用ORACLE的动态执行SQL的机制Executeimmediate，这样就可以完全避免${}出现的可能性了。这样会引入比较复杂的模型，这个时候，你就需要取舍了。
针对于以上动态SQL所导致的问题，最激进的方式是全部采用存储过程，用数据库原生的方式来解决，方便开发调试，当然也会带来问题：对开发人员会有更高的要求、存储过程的管理等等，我这边项目没有采用过这种方式，这里不做更多的展开。
5.简单使用Mybatis。
Mybatis的功能相对而言还是比较弱的，缺少了好多必要的辅助库，字符串处理等等，扩展也比较困难，一般也就可能对返回值进行一些处理。因此最好仅仅把它作为单纯的SQL配置文件，以及简单的ORM框架。不要尝试在Mybatis中做过多的动态SQL，否则会导致后续的维护非常恶心。
以上所述是小编给大家介绍的Mybatis学习总结之mybatis使用建议，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对毛票票网站的支持！