mybatis最佳实践
2017年02月09日

原则:

1. sql和代码分离,sql易于维护和 检查评审。

2. 高度的自动化和封装,减少开发工作量。


从原则上讲:

  • 也不能像jdbc那样,SQL和代码混写,不方便检查和审核。

  • Mybatis的Example用法,其实不过是sql拼接的语法糖,和sql与代码混写没多少区别(不方便检查和审核),不推荐使用

  • 同样,类似于hibernate那样的对象操作方式,其实也是sql拼接的语法糖,不建议使用。

  • 要避免像hibernate那样过度封装,形成很多新的语法(HSQL)

    总之,我们不推荐 以任何形式 自由地 生成自定义的SQL,不管是java代码也好,还是新语法(伪SQL)也好。

    我们建议的是,直接写sql,但是确保sql与代码分离,这样比较纯粹,就是直接通过sql去取数据,借助Mybatis完成数据实体的自动封装,以及代码的自动生成罢了。

  • sql是一门最基础的语言,程序员们都应该熟练掌握;

  • 我们的工具,不能让程序员们忘记了SQL怎么写,这是原则,如果真的有一个工具,能够让程序员忘记SQL怎么写,我认为是百害而无益。


特别说明:注意,我们是不推荐 程序员在代码中去自由的自定义SQL,以防止SQL质量不受控制,但是我们可以定义一些固定的SQL模板,让程序员们直接套用,这些SQL模板是经得起质量考验的,不会存在性能和安全隐患。这就是 Mybatis“通用Mapper”的功能。


    所以,我们可以进一步增强mybatis的代码生成和自动封装功能:(国产开源的通用Mapper是一个榜样)

    就通用Mapper而言,有如下几个改进方向:

  • 目前标准mapper有11个方法,除掉前面所说的Example,是否够用,是否还能再添加一些常用的接口?这是一个改进方向(但是要坚持严格的原则,杜绝存在性能和安全隐患的sql模板)。

  • 另外,标准的mapper都是独立的,没有一个统一的父类,不方便在某些动态注入mapper的场景下使用,这一点局限性很大,是一个改进方向。

  • 还有,加入通用分页方法,PageHelper这种方法很好用,让sql只专注于业务,分页交给框架去处理。

  • 另外,id自动生成,insert和update部分数据没设置值时自动填充(比如 updateTime createTime)。

    

我研发的企业级开发框架(FAST),就对 mabatis+通用mapper 进行了增强,具体可以查看 FAST框架的相关说明文档。