mybatis配置文件中查询方法?前言MyBatis是常见的Java数据库访问层框架，它的前身是 Apache 的开源项目 iBatisMyBatis 消除了几乎所有的 JDBC 代码和参数的手工设置以及对结果集的检索封装，是一个支持普通 SQL 查询，存储过程和高级映射的基于 Java 的优秀持久层框架在日常工作中，开发人员多数情况下是对底层的原理一知半解因此带着个人的兴趣，希望从应用及源码的角度为读者梳理MyBatis的底层机制，下面我们就来说一说关于mybatis配置文件中查询方法?我们一起去了解并探讨一下这个问题吧!
mybatis配置文件中查询方法
前言
MyBatis是常见的Java数据库访问层框架，它的前身是 Apache 的开源项目 iBatis。MyBatis 消除了几乎所有的 JDBC 代码和参数的手工设置以及对结果集的检索封装，是一个支持普通 SQL 查询，存储过程和高级映射的基于 Java 的优秀持久层框架。在日常工作中，开发人员多数情况下是对底层的原理一知半解。因此带着个人的兴趣，希望从应用及源码的角度为读者梳理MyBatis的底层机制。
目录
本文按照以下顺序展开。
Mybatis的配置文件以及相关介绍
在MyBatis的整个生命周期中，包含两类配置文件，一类是配置基本信息的MyBatis.xml(该名称可以自定义)，一类是定义具体sql的xxxMapper.xml文件，接下来我们就深入了解这两个文件的设计理念和他绝妙的底层设计。
俯瞰整个流程设计
从上图可知，我们开发一个Mybatis应用的基本流程非常简单，但是其中的配置文件是怎样一步步转换为我们熟悉的java对象呢，他们之间又是如何相交甚欢呢？跟着我的脚步，让我们一起深入腹地，剥开这层神秘的面纱。
mybatis.xml核心配置文件解析
由上图可知，我们将mybatis.xml文件转换为流后传入了SqlSessionFactoryBuilder，使用构造者模式调用方法build(…)之后返回Session工厂,我们只讲解有配置文件的，因此方法后两个参数为null,如下图所示：
XMLConfigBuilder底层使用的是 DOM 解析方式，并配合使用 XPath 解析 XML 配置文件，XML 常见的解析方式有以下两种： DOM、 SAX :
DOM 方式
DOM 基于树形结构解析， 它会将整个文档读入内存并构建一个 DOM 树， 基于这棵树的结构对各个节点进行解析。
优点：a.形成了树结构，直观好理解，代码更易编写
b.解析过程中树结构保留在内存中，方便修改
缺点：
a.当xml文件较大时，对内存耗费比较大，容易影响解析性能并且造成内存溢出
SAX 方式
SAX 是基于事件模型的 XML 解析方式， 它不需要将整个 XML 文档加载到内存中， 而只需要将一部分 XML 文档的一部分加载到内存中， 即可开始解析。
优点：a.采用事件驱动模式，对内存耗费比较小
b.适用于只需要处理xml中数据时
缺点：a.不易编码（需要借助handler来进行解析）
b.很难同时访问同一个xml中的多处不同数据（事件有先后顺序的）
具体为什么Mybatis使用DOM而不使用SAX,大家可以后续思考
接着调用parse()方法开始解析具体的xml节点信息，如下图所示：
settings可配置值参考：
http://blog.csdn.net/fageweiketang/article/details/80767532
在setting解析中，我们需要注意一个缓存默认值的设置，即cacheEnabled，如下图所示，它标志着我们在执行sql时到底使用什么执行器去完成我们的业务操作：
plugins是我们自定义的插件，用于扩展我们的4大对象，四大对象分别为Execute,StatementHandler,ParameterHandler和ResultSetHandler,在执行流程解析我们会详细讲解
下面我们主要讲解一下environments和mappers，environments配置了我们底层使用的数据库连接信息。而mappers定义了我们执行的具体sql查询。
environments执行流程如下，执行完成后将Environment对象添加到Config对象中：
mappers节点里面可以配置多种用于解析具体xml文件的方式，我们只关注resource方式，通过该配置我们可以获取到具体的xxxMapper,xml文件，然后通过XMLMapperBuilder类的parse()进行后续的处理，如下图所示：
我们首先看一下bindMapperForNamespace方法，该方法主要是处理我们mapper标签中的namespace值，如下所示
addMapper(boundType)内部调用了mapperRegistry.addMapper方法用于创建代理工厂对象，MapperRegistry是Config内部非常重要的实例变量，它存储了所有的接口对应的代理工厂对象，后续获取Mapper对象都是通过该对象获取：
开始解析mapper标签下面的所有信息，如下图所示
其中buildStatementFromContext（）就是我们的核心方法了，该方法底层调用了parseStatementNode()方法,parseStatementNode（）将我们的CRUD中的各个子标签以及配置的属性进行转换最终生成一个MapperedStatemanet对象并且存储到Config对象中的mappedStatements变量里。
public void parseStatementNode() {
String id = context.getStringAttribute("id");
String databaseId = context.getStringAttribute("databaseId");
if (!databaseIdMatchesCurrent(id, databaseId, this.requiredDatabaseId)) {
return;
}
String nodeName = context.getNode().getNodeName();
SqlCommandType sqlCommandType = SqlCommandType.valueOf(nodeName.toUpperCase(Locale.ENGLISH));
boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
//是否刷新缓存 默认值:增删改刷新 查询不刷新
boolean flushCache = context.getBooleanAttribute("flushCache", !isSelect);
//是否使用二级缓存 默认值:查询使用 增删改不使用
boolean useCache = context.getBooleanAttribute("useCache", isSelect);
boolean resultOrdered = context.getBooleanAttribute("resultOrdered", false);
//替换Includes标签为对应的sql标签里面的值
//具体配置使用可参考http://blog.csdn.net/qq_36761831/article/details/88698102
XMLIncludeTransformer includeParser = new XMLIncludeTransformer(configuration, builderAssistant);
includeParser.applyIncludes(context.getNode());
//传入参数
String parameterType = context.getStringAttribute("parameterType");
Class<?> parameterTypeClass = resolveClass(parameterType);
//解析配置的自定义脚本语言驱动 mybatis plus
//用于解析具体的sql语句
String lang = context.getStringAttribute("lang");
LanguageDriver langDriver = getLanguageDriver(lang);
//解析selectKey，该标签使用与insert、update标签内，通过一个查询，把返回结果作为主键
//其中的order属性设置需要注意，配置了自增的需要配置为AFTER,使用序列的配置为BEFORE
//生成KeyGenerator对象添加到Config对象的keyGenerators变量中
processSelectKeyNodes(id, parameterTypeClass, langDriver);
// Parse the SQL (pre: <selectKey> and <include> were parsed and removed)
//设置主键自增规则,只能在insert使用
KeyGenerator keyGenerator;
String keyStatementId = id SelectKeyGenerator.SELECT_KEY_SUFFIX;
keyStatementId = builderAssistant.applyCurrentNamespace(keyStatementId, true);
if (configuration.hasKeyGenerator(keyStatementId)) {
keyGenerator = configuration.getKeyGenerator(keyStatementId);
} else {
keyGenerator = context.getBooleanAttribute("useGeneratedKeys",
configuration.isUseGeneratedKeys() && SqlCommandType.INSERT.equals(sqlCommandType))
? Jdbc3KeyGenerator.INSTANCE : NoKeyGenerator.INSTANCE;
}
//解析Sql 根据sql文本来判断是否需要动态解析 如果没有动态sql语句且 只有#{}的时候 直接静态解析使用?占位 当有 ${} 不解析
SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
StatementType statementType = StatementType.valueOf(context.getStringAttribute("statementType", StatementType.PREPARED.toString()));
Integer fetchSize = context.getIntAttribute("fetchSize");
Integer timeout = context.getIntAttribute("timeout");
String parameterMap = context.getStringAttribute("parameterMap");
String resultType = context.getStringAttribute("resultType");
Class<?> resultTypeClass = resolveClass(resultType);
String resultMap = context.getStringAttribute("resultMap");
String resultSetType = context.getStringAttribute("resultSetType");
ResultSetType resultSetTypeEnum = resolveResultSetType(resultSetType);
if (resultSetTypeEnum == null) {
resultSetTypeEnum = configuration.getDefaultResultSetType();
}
String keyProperty = context.getStringAttribute("keyProperty");
String keyColumn = context.getStringAttribute("keyColumn");
String resultSets = context.getStringAttribute("resultSets");
builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
resultSetTypeEnum, flushCache, useCache, resultOrdered,
keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);
}
下面我们分析其中最重要的SqlSource对象生成所对应的LanguageDriver接口的createSqlSource方法,LanguageDriver默认的实现类为XMLLanguageDriver。该方法判断我们创建的sql是否是动态sql,动态sql包含${}标识符，静态sql只有#{}标识，当只有静态sql时，在此处便将#{}替换为占位符？，否则会在真正调用查询接口的时候去替换。
总结：
配置文件的解析其实很简单，它主要的作用就是将我们的配置转换为我们对应的java实体类然后供后续执行时调用，下面我们一起来看一下整体的解析过程：
通过上图分析，我们发现它的整个解析流程非常优雅，每个重要模块的解析都是由单独的对象进行处理的，每个类的分工非常明确，我们在研究源码的时候不仅要注意他的实现方式还有学习其中的设计，这也提升我们编码水平的重要途径。
如有不准确的地方，欢迎指正，谢谢
