场景：项目中用到mybatis(版本3.3.2)。对于单表操作，我们一开始是手写各个sql。但是这样接口非常不一致，而且有太多的小接口，不方便讲相似功能合并。而且由于实现不一致，不能只根据接口名判断具体执行的sql，而且不能保证没有bug。后来我们用mybatis-generator插件，自动生成model、example、mapper.xml、mapper.java。但是又引入了新的问题。表重构时，自动生成的代码特别是mapper.xml需要重新生成。当里面有手写的一些sql时，要手动处理它们。并且自动生成的模板代码非常多。非常相似的内容存在各个文件中。可读性比较差。于是希望找到一种mybatis通用dao的实现。从网上找了一些答案，实现都不是非常优雅，功能也不是特别强。有的用jpa注解在model（entity）里加注解，感觉实现起来太麻烦，而且又由于在xml中还有手写的sql，字段映射在model和xml中冗余存在。有的强制采用默认方式，要求字段名和属性名如何对应。这些实现都不优雅，而且没有我想要的功能-融合单表操作的example方式的增删查改。
于是开始了自己探索实现mybatis通用dao之路。
思路一：
mybatis支持注解方式提供sql，一种是Select、Insert、Delete、Update，另一种是Provider方式。经过阅读源码以及网上学习，知道第一种支持在DynamicSqlSource（动态sql，支持写<where>、<if>等标签），第二种只支持RawSqlSource（支持占位符的sql，sql中可以有#{}这样的占位符），当然第一种也支持占位符。所以思路一是修改mybatis源码，将org.apache.ibatis.builder.annotation.MapperAnnotationBuilder作修改
private SqlSource getSqlSourceFromAnnotations(Method method, Class<?> parameterType, LanguageDriver languageDriver) {
try {
Class<? extends Annotation> sqlAnnotationType = getSqlAnnotationType(method);
Class<? extends Annotation> sqlProviderAnnotationType = getSqlProviderAnnotationType(method);
if (sqlAnnotationType != null) {
if (sqlProviderAnnotationType != null) {
throw new BindingException("You cannot supply both a static SQL and SqlProvider to method named " + method.getName());
}
Annotation sqlAnnotation = method.getAnnotation(sqlAnnotationType);
final String[] strings = (String[]) sqlAnnotation.getClass().getMethod("value").invoke(sqlAnnotation);
return buildSqlSourceFromStrings(strings, parameterType, languageDriver);
} else if (sqlProviderAnnotationType != null) {
Annotation sqlProviderAnnotation = method.getAnnotation(sqlProviderAnnotationType);
//TODO modified by zhoujiaping,at 2017-05-14 修改源码，支持SqlProvider写带标签的动态sql。
if(ProviderHelper.isScriptSqlProvider(sqlProviderAnnotation, sqlProviderAnnotationType)){
String string = ProviderHelper.create(assistant,method, sqlProviderAnnotation, sqlProviderAnnotationType).getSql();
return buildSqlSourceFromStrings(new String[]{string},parameterType,languageDriver);
}else{
return new ProviderSqlSource(assistant.getConfiguration(), sqlProviderAnnotation);
}
}
return null;
} catch (Exception e) {
throw new BuilderException("Could not find value method on SQL annotation. Cause: " + e, e);
}
}
完整代码参考:https://github.com/zhoujiaping/mybatis-howso.git 和 https://github.com/zhoujiaping/mybatis-basemapper.git
功能确实是实现了，有个小问题，每次都重复执行生成sql的代码。效率可能会受影响（没测过效率），不过这可以通过缓存生成的sql解决。
更大的问题是，修改了源码。修改源码意味着代码可靠性下降。尽量不要把修改的源码用于生产环境。但是我的初衷就是用于生产环境啊。
思路二：
在mybatis读取配置时，适当的时候拓展一些行为。于是在mybatis读取mapper.xml时，将mapper.xml替换为自动生成的sql和手写的sql文件。
功能是实现了，这个实现的代码在 https://github.com/zhoujiaping/mybatis-mapper.git 的历史版本里。因为缺点太明显了，dom解析速度太慢，即使用了java8的并行流，还是不够快。
思路三：
基于mybatis拦截器插件机制实现。
这个思路其实是最开始的思路，但是由于一开始对mybatis原理一点都不理解（用mybatis不久），所以尝试了也没找到方法。后来，根据前面的实现，再看了两次源码，发现这个思路是可行的。于是又开始尝试。
代码：https://github.com/zhoujiaping/mybatis-mapper.git
这个版本算是最终版本了。优点，单表操作的配置量极少，就实现了强大的功能。重构时非常方便。使用、理解起来也非常方法。一致的api、保证项目中各成员写的代码逻辑一致。强大的功能，使我们在做单表处理时的业务逻辑，尽可能的写在业务层而不用写在sql中。对性能的影响，几乎可以忽略不计。除非插件机制本身带来的性能问题，该插件不会降低性能。因为生成sql的语句，只在第一次对应接口被调用时执行。并发问题也已经被考虑被解决（其实只执行一次的代码，并发问题并不严重）。插件易用，学习成本非常低。