对于一个和数据库打交道的程序员来说，很快会面临着一个艰难的选择。到底是选择MyBatis还是JPA呢？
很多人说，技术选择，都要根据需求来，这个没错。但是，除了需求，还有很重要的一个环节，那就是队友的水平。如果你选择了一些比较高级的技术，那么就是在给整个团队埋坑。
JPA的抽象层次更高，代码写起来也更简洁，但是它一点都不简单。虽然经过了多次的培训，我呆过的几个团队，还是把它用的和屎一样。
我扔掉了JPA
我仔细想了一下，有下面几点原因，造成了JPA在很多团队根本就玩不下去。
所以，不是JPA不好，而是它不符合国情而已。想要在公司内推行JPA，你需要给我一个稳定的产品团队、一个牛X的技术团队才行。
所以，大多数公司宁可写一堆重复的、乱七八糟的Mybaits代码，也不会轻易尝试JPA，这是符合逻辑的，符合事物发展规律的。
所以，我们下面的文章就是来讨论MyBatis的，来看一下Mybaits到底要怎么写才算优雅。
MyBatis为什么不好用
优秀的程序员都是很懒的。所以很多人不想设计实体的sql。JPA可以直接根据Java的实体代码，生成sql的库表，这在使用Mybatis的人来看，是非常羡慕的。
使用MyBatis，要倒着来。需要先设计库表，然后根据库表反向生成一堆Java代码和配置文件。
这个代码生成器，就是mybatis-generator。
但是，请注意。这个生成器生成的代码，有四种模式！！！这就是最让初学者难受的地方。如果你也是刚接触MyBatis，强烈推荐只关注下面第一种模式。
所以，下面仅仅介绍MyBatis3模式的代码生成。
要使用它，需要在pom.xml里加入它的依赖。
<dependency> <groupId>org.mybatis.generator</groupId> <artifactId>mybatis-generator-core</artifactId> <optional>true</optional> <scope>test</scope> <version>1.4.0</version> </dependency>
我个人喜欢使用Java代码来操作代码生成这个过程，所以下面就是生成代码的代码。
public class MBGTool {
public static void main(String[] args) throws Exception {
List<String> warnings = new ArrayList<>();
boolean overwrite = true;
InputStream configFile = MBGTool.class.getResourceAsStream("/generator/generatorConfig.xml");
ConfigurationParser cp = new ConfigurationParser(warnings);
Configuration config = cp.parseConfiguration(configFile);
DefaultShellCallback callback = new DefaultShellCallback(overwrite);
MyBatisGenerator myBatisGenerator = new MyBatisGenerator(config, callback, warnings);
myBatisGenerator.generate(null);
}
}
从代码中，我们可以看到需要配置一个generatorConfig.xml文件，用来规定怎么生成代码文件。
<!DOCTYPE generatorConfiguration PUBLIC
"-//mybatis.org//DTD MyBatis Generator Configuration 1.0//EN"
"http://mybatis.org/dtd/mybatis-generator-config_1_0.dtd">
<generatorConfiguration>
<context id="simple" targetRuntime="MyBatis3">
<jdbcConnection driverClass="com.mysql.cj.jdbc.Driver"
connectionURL="jdbc:mysql://localhost:3306/mbye"
userId="root"
password="root"
/>
<javaModelGenerator targetPackage="com.github.javarunfast.mbye.domain" targetProject="src/main/java">
<property name="enableSubPackages" value="true"/>
<property name="trimStrings" value="true"/>
</javaModelGenerator>
<sqlMapGenerator targetPackage="com.github.javarunfast.mbye.mapper" targetProject="src/main/resources"/>
<javaClientGenerator type="XMLMAPPER" targetPackage="com.github.javarunfast.mbye.mapper" targetProject="src/main/java">
<property name="enableSubPackages" value="true"/>
</javaClientGenerator>
<table tableName="test"/>
</context>
</generatorConfiguration>
运行我们的MBGTool文件之后，就可以生成MyBatis的代码了。
怎么写代码最优雅
但是，我这里并不是要推荐你使用这种模式。因为，它生成了一大堆无用的文件。假如你的项目使用了sonar这样的代码质量审查工具，你会发现很多飘红的地方，还有那要命的覆盖率问题。
怎么办？
经过我多年的摸索，我现在推荐一种非常好用的写法。自从我采用了这种方式之后，就再也没有换过。
第一、不需要代码生成器了
数据表的设计，还有domain的书写，全部靠手工。这样我们的代码，如果有必要，还可以迁移到JPA上去。这种模式还能顺便学习一下Java里面的数据类型，是如何和SQL里的数据类型一一对应的。在做表设计的时候，顺便能够了解一些背后的原理。
第二、不需要写映射文件了
生成器生成的东西，确实是有一堆无用的逻辑。比如我的某个数据表，根本不需要提供查询所有和删除这种动作，它还是默认提供了。
在这种简约模式下，我们直接手写Mapper文件，然后只声明所需要的接口方法就可以了。
@Mapper
public interface AccountBasicMapper {
@Insert("AccountBasicMapper/insert.sql")
void insert(@Param("r") AccountBasic record);
}
可以看到，里面有一个Insert注解，我们传入了一个具体的domain，然后，就可以在AccountBasicMapper目录下的insert.sql文件里，书写具体的sql语句了。
sql语句样例如下：
INSERT INTO account_basic( account_id, nick_name, password, sex, state, photo_url, created, modified, version )VALUES ( <@p name="r.accountId"/>, <@p name="r.nickName"/>, <@p name="r.password"/>, <@p name="r.sex"/>, <@p name="r.state"/>, <@p name="r.photoUrl"/>, <@p name="r.created"/>, <@p name="r.modified"/>, <@p name="r.version"/> )
那么这是什么语法呢？它又是如何知道是这样配置的呢？这就需要引入MyBatis的脚本语言配置功能。在这里，我们使用的freemark的模版。
不要忘了加入它的依赖。
<dependency> <groupId>org.mybatis.scripting</groupId> <artifactId>mybatis-freemarker</artifactId> <version>1.2.2</version> </dependency>
然后，在yaml文件里做上相应的配置就ok了。
mybatis:
check_config_location: false
scripting-language-driver:
freemarker:
template-file:
base-dir: mappers/
path-provider:
includes-package-path: false
separate-directory-per-mapper: false
这种方式的好处和坏处
我个人是非常喜欢这种模式的。因为它有下面几个好处：
当然，缺点也是显而易见的。
不过，我并不认为这是个问题。每一个方法配备一个sql文件，代码写起来反而更加简单了。当出现问题的时候，也不用根据逻辑进行跟踪定位到拼接后的SQL语句。我现在，只需要拿到对应方法的SQL文件，就可以改吧改吧，直接在sql终端里执行调试。这样，sql优化也变的简单了。
当然，一个人一个习惯。我个人喜欢这种模式，而且在我的团队里推行这种模式，发现运行的也很好。另外，程序员为了少写重复的sql代码，在设计Dao接口的时候，反而更加认真了。
这可能是一个额外的收获吧。
到此这篇关于MyBatis还是JPA?终于有答案了的文章就介绍到这了,更多相关MyBatis还是JPA内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
