MyBatis学习总结(16)Mybatis使用的几个建议
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中包含大量的空格,增加网络传输的时间,也不可取。
而且大量的if choose语句,不可避免地,每次生成的SQL会不太一致,会导致ORACLE大量的硬解析,也不可取。我们来看看这样的SQL:
SELECT * FROM T_NEWS_TEXT WHERE 1 = 1
choose>
if
推荐阅读
-
MyBatis学习总结(16)Mybatis使用的几个建议
-
Spring + mybatis + mysql使用事物的几种方法总结
-
Spring + mybatis + mysql使用事物的几种方法总结
-
mybatis-plus如何使用的一些问题经验总结
-
使用mybatis分页插件PageHelper5.0.0遇到的问题总结
-
Mybatis分页插件PageHelper的学习与使用
-
java学习笔记(中级篇)—细说mybatis的使用方式
-
【原创】Mybatis学习笔记(二)——一些写mapper配置使用的最佳实践
-
【原创】Mybatis学习笔记(二)——一些写mapper配置使用的最佳实践
-
mybatis-plus如何使用的一些问题经验总结