原则：

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

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

从原则上讲：

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

• 不推荐在代码中以任何方式组装任意SQL，比如Mybatis的Example用法，其实不过是sql拼接的语法糖，和sql与代码混写没多少区别（不方便检查和审核），不推荐使用；

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

• 要避免像hibernate那样过度封装，形成很多新的语法（HSQL），最关键是无法控制SQL质量。

    总之，我们不推荐 以任何形式 自由地 生成自定义的SQL，不管是java代码（对象操作）也好，还是新语法（伪SQL）也好。

    我们建议的是，框架提供对日常简单SQL语句封装，这种情况下不需要写SQL。但对于较复杂的SQL，则直接写在配置文件中（xml），确保sql与代码分离，这样比较纯粹，就是直接通过sql去取数据，借助Mybatis完成数据实体的自动封装，以及代码的自动生成罢了。

    还考虑到了以下两点：

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

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

特别说明：

1、

    注意，我们是不推荐 程序员在代码中去自由的自定义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框架的相关说明文档。

2、

    以上原则，已经禁用了通过Mybatis Example 或 Mybatis-Plus（或类似框架）在Java代码中组装SQL的用法。原因很简单，对个人项目而言，Java代码中组装SQL很方便、快捷，但是对企业团队、长期维护的项目来说，质量和可维护性堪忧。

    我们的企业级开发框架中，吸取了Mybatis-Plus的精华，去除了不合适团队开发的部分。