MyBatis学习总结（16）Mybatis使用的几个建议

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MyBatis学习总结（16）Mybatis使用的几个建议，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6260字，纯文字阅读大概需要9分钟。

内容图文

1.Mapper层参数为Map,由Service层负责重载。 Mapper由于机制的问题，不能重载，参数一般设置成Map，但这样会使参数变得模糊，如果想要使代码变得清晰，可以通过service层来实现重载的目的，对外提供的Service层是重载的，但这些重载的Service方法其实是调同

1.Mapper层参数为Map,由Service层负责重载。

Mapper由于机制的问题，不能重载，参数一般设置成Map，但这样会使参数变得模糊，如果想要使代码变得清晰，可以通过service层来实现重载的目的，对外提供的Service层是重载的，但这些重载的Service方法其实是调同一个Mapper，只不过相应的参数并不一致。

也许有人会想，为什么不在Service层也设置成Map呢？我个人是不推荐这么做的，虽然为了方便，我在之前的项目中也大量采用了这种方式，但很明显会给日后的维护工作带来麻烦。因为这么做会使你整个MVC都依赖于Map模型，这个模型其实是很不错的，方便搭框架，但存在一个问题：仅仅看方法签名，你不清楚Map中所拥有的参数个数、类型、每个参数代表的含义。

试想，你只对Service层变更，或者DAO层变更，你需要清楚整个流程中Map传递过来的参数，除非你注释或者文档良好，否则必须把每一层的代码都了解清楚，你才知道传递了哪些参数。针对于简单MVC，那倒也还好，但如果层次复杂之后，代码会变得异常复杂，而且如果我增加一个参数，需要把每一个层的注释都添加上。相对于注释，使用方法签名来保证这种代码可控性会来得更可行一些，因为注释有可能是过时的，但方法签名一般不太可能是陈旧的。

2.尽量少用if choose等语句，降低维护的难度。

Mybatis的配置SQL时，尽量少用if choose 等标签，能用SQL实现判断的尽量用SQL来判断(CASE WHEN ,DECODE等)，以便后期维护。否则，一旦SQL膨胀，超级恶心，如果需要调试Mybatis中的SQL，需要去除大量的判断语句，非常麻烦。另一方面，大量的if判断，会使生成的SQL中包含大量的空格，增加网络传输的时间，也不可取。

SELECT * FROM T_NEWS_TEXT WHERE 1 = 1
< choose>
< if test ="startdate != null and startdate != '' and enddate != null and endate != ''">
AND PUBLISHTIME >= #{startdate} AND PUBLISHTIME <= #{enddate}
if>

AND PUBLISHTIME >= SYSDATE - 7 AND PUBLISHTIME <= SYSDATE
choose >

SELECT * FROM T_NEWS_TEXT WHERE PUBLISHTIME >= DECODE(#{startdate},NULL,SYSDATE-7, #{startdate}) AND PUBLISHTIME <= DECODE(#{enddate},NULL,SYSDATE,#{enddate})

当然有人会想，引入CASE WHEN,DECODE会导致需要ORACLE函数解析，会拖慢SQL执行时间，有兴趣的同学可以回去做一下测试，看看是否会有大的影响。就个人经验而言，在我的开发过程，没有发现因为函数解析导致SQL变慢的情形。影响SQL执行效率的一般情况下是JOIN、ORDER BY、DISTINCT、PARTITATION BY等这些操作，这些操作一般与表结构设计有很大的关联。相对于这些的效率影响程度，函数解析对于SQL执行速度影响应该是可以忽略不计的。

另外一点，对于一些默认值的赋值，像上面那条SQL，默认成当前日期什么的，其实可以完全提到Service层或Controller层做处理，在Mybatis中应该要少用这些判断。因为，这样的话，很难做缓存处理。如果startdate为空，在SQL上使用动态的SYSDATE，就无法确定缓存startdate日期的key应该是什么了。所以参数最好在传递至Mybatis之前都处理好，这样Mybatis层也能减少部分if choose语句，同时也方便做缓存处理。

当然不使用if choose也并不是绝对的，有时候为了优化SQL，不得不使用if来解决，比如说LIKE语句，当然一般不推荐使用LIKE，但如果存在使用的场景，尽可能在不需要使用时候去除LIKE，比如查询文章标题，以提高查询效率。 最好的方式是使用lucence等搜索引擎来解决这种全文索引的问题。

3.用XML注释取代SQL注释。

Mybatis中原SQL的注释尽量不要保留，注释会引发一些问题，如果需要使用注释，可以在XML中用来注释，保证在生成的SQL中不会存在SQL注释，从而降低问题出现的可能性。这样做还有一个好处，就是在IDE中可以很清楚的区分注释与SQL。

SELECT * FROM TEST WHERE COL1 >  1 -- 这里是注释<if test="a != null and a != ''">AND COL2 = #{a}if>

4.尽可能使用#{}，而不是${}.

Mybatis中尽量不要使用${}，尽量这样做很方便开发，但是有一个问题，就是大量使用会导致ORACLE的硬解析，拖慢数据库性能，运行越久，数据库性能会越差。对于一般多个字符串IN的处理，可以参考如下的解决方案:http://www.myexception.cn/sql/849573.html，基本可以解决大部分${}.

关于${}，另一个误用的地方就是LIKE，我这边还有个案例：比如一些树型菜单，节点会设计成'01','0101',用两位节点来区分层级，这时候，如果需要查询01节点下所有的节点，最简单的SQL便是:SELECT * FROM TREE WHERE ID LIKE '01%',这种SQL其实无可厚非，因为它也能用到索引，所以不需要特别的处理，直接使用就行了。但如果是文章标题，则需要额外注意了：SELECT * FROM T_NEWS_TEXT WHERE TITLE LIKE '%OSC%'，这是怎么也不会用到索引的，上面说了，最好采用全文检索。但如果离不开LIKE，就需要注意使用的方式： ID LIKE #{ID} || '%'而不是ID LIKE '${ID}%'，减少硬解析的可能。

有人觉得使用||会增加ORACLE处理的时间，我觉得不要把ORACLE看得太傻，虽然有时候确实非常傻，有空可以再总结ORACLE傻不垃圾的地方，但是稍加测试便知：这种串联方式，对于整个SQL的解析执行，应该是微乎其微的。

当然还有一些特殊情况是没有办法处理的，比如说动态注入列名、表名等。对于这些情况，则比较棘手，没有找到比较方便的手段。由于这种情况出现的可能性会比较少，所以使用${}倒也不至于有什么太大的影响。当然你如果有代码洁癖的话，可以使用ORACLE的动态执行SQL的机制Execute immediate，这样就可以完全避免${}出现的可能性了。这样会引入比较复杂的模型，这个时候，你就需要取舍了。

5.简单使用Mybatis。

Mybatis的功能相对而言还是比较弱的，缺少了好多必要的辅助库，字符串处理等等，扩展也比较困难，一般也就可能对返回值进行一些处理。因此最好仅仅把它作为单纯的SQL配置文件，以及简单的ORM框架。不要尝试在Mybatis中做过多的动态SQL，否则会导致后续的维护非常恶心。

内容总结

以上是互联网集市为您收集整理的MyBatis学习总结（16）Mybatis使用的几个建议全部内容，希望文章能够帮你解决MyBatis学习总结（16）Mybatis使用的几个建议所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端