mybatis操作数据库的过程
// 第一步：读取mybatis-config.xml配置文件
InputStream inputStream = Resources.getResourceAsStream("mybatis-config.xml");
// 第二步：构建SqlSessionFactory(框架初始化)
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().bulid();
// 第三步：打开sqlSession
SqlSession session = sqlSessionFactory.openSession();
// 第四步：获取Mapper接口对象（底层是动态代理）
AccountMapper accountMapper = session.getMapper(AccountMapper.class);
// 第五步：调用Mapper接口对象的方法操作数据库;
Account account = accountMapper.selectByPrimaryKey(1);
通过调用session.getMapper(AccountMapper.class)所得到的AccountMapper 是一个动态代理对象，所以执行accountMapper.selectByPrimaryKey(1)方法前，都会被invoke()拦截，先执行invoke()中的逻辑。
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
try {
// 要执行的方法所在的类如果是Object,直接调用，不做拦截处理
if (Object.class.equals(method.getDeclaringClass())) {
return method.invoke(this, args);
//如果是默认方法，也就是java8中的default方法
} else if (isDefaultMethod(method)) {
// 直接执行default方法
return invokeDefaultMethod(proxy, method, args);
}
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
// 从缓存中获取MapperMethod
final MapperMethod mapperMethod = cachedMapperMethod(method);
return mapperMethod.execute(sqlSession, args);
}
从methodCache获取对应DAO方法的MapperMethod
MapperMethod的主要功能是执行SQL语句的相关操作，在初始化的时候会实例化两个对象：SqlCommand（Sql命令）和 MethodSignature（方法签名）。
/**
* 根据Mapper接口类型、接口方法、核心配置对象 构造MapperMethod对象
* @param mapperInterface
* @param method
* @param config
*/
public MapperMethod(Class mapperInterface, Method method, Configuration config) {
this.command = new SqlCommand(config, mapperInterface, method);
// 将Mapper接口中的数据库操作方法(如Account selectById(Integer id);)封装成方法签名MethodSignature
this.method = new MethodSignature(config, mapperInterface, method);
}
new SqlCommand（）调用SqlCommand类构造方法：
public SqlCommand(Configuration configuration, Class mapperInterface, Method method) {
// 获取Mapper接口中要执行的某个方法的方法名
// 如accountMapper.selectByPrimaryKey(1)
final String methodName = method.getName();
// 获取方法所在的类
final Class declaringClass = method.getDeclaringClass();
// 解析得到Mapper语句对象(对配置文件中的中的sql语句进行封装)
MappedStatement ms = resolveMappedStatement(mapperInterface, methodName, declaringClass,
configuration);
if (ms == null) {
if (method.getAnnotation(Flush.class) != null) {
name = null;
type = SqlCommandType.FLUSH;
} else {
throw new BindingException("Invalid bound statement (not found): "
+ mapperInterface.getName() + "." + methodName);
}
} else {
// 如com.bjpowernode.mapper.AccountMapper.selectByPrimaryKey
name = ms.getId();
// SQL类型：增 删 改 查
type = ms.getSqlCommandType();
if (type == SqlCommandType.UNKNOWN) {
throw new BindingException("Unknown execution method for: " + name);
}
}
}
private MapperMethod cachedMapperMethod(Method method) {
MapperMethod mapperMethod = (MapperMethod)this.methodCache.get(method);
if (mapperMethod == null) {
mapperMethod = new MapperMethod(this.mapperInterface, method, this.sqlSession.getConfiguration());
this.methodCache.put(method, mapperMethod);
}
return mapperMethod;
}
调用mapperMethod.execute(sqlSession, args)
在mapperMethod.execute()方法中，我们可以看到：mybatis定义了5种SQL操作类型：insert/update/delete/select/flush。其中，select操作类型又可以分为五类，这五类的返回结果都不同，分别对应：
•返回参数为空：executeWithResultHandler()；
•查询多条记录：executeForMany()，返回对象为JavaBean
•返参对象为map：executeForMap()， 通过该方法查询数据库，最终的返回结果不是JavaBean，而是Map
•游标查询：executeForCursor()；关于什么是游标查询，自行百度哈；
•查询单条记录： sqlSession.selectOne()，通过该查询方法，最终只会返回一条结果；
通过源码追踪我们可以不难发现：当调用mapperMethod.execute() 执行SQL语句的时候，无论是insert/update/delete/flush，还是select（包括5种不同的select）, 本质上时通过sqlSession调用的。在SELECT操作中,虽然调用了MapperMethod中的方法,但本质上仍是通过Sqlsession下的select(), selectList(), selectCursor(), selectMap()等方法实现的。
而SqlSession的内部实现，最终是调用执行器Executor（后面会细说）。这里，我们可以先大概看一下mybatis在执行SQL语句的时候的调用过程：
以accountMapper.selectByPrimaryKey(1)为例：
•调用SqlSession.getMapper()：得到xxxMapper(如UserMapper)的动态代理对象；
•调用accountMapper.selectByPrimaryKey(1)：在xxxMapper动态代理内部，会根据要执行的SQL语句类型(insert/update/delete/select/flush)来调用SqlSession对应的不同方法，如sqlSession.insert()；
•在sqlSession.insert()方法的实现逻辑中，又会转交给executor.query()进行查询；
•executor.query()又最终会转交给statement类进行操作，到这里就是jdbc操作了。
有人会好奇，为什么要通过不断的转交，SqlSession->Executor->Statement，而不是直接调用Statement执行SQL语句呢？因为在调用Statement之前，会处理一些共性的逻辑，如在Executor的实现类BaseExecutor会有一级缓存相关的逻辑，在CachingExecutor中会有二级缓存的相关逻辑。如果直接调用Statement执行SQL语句，那么在每个Statement的实现类中，都要写一套一级缓存和二级缓存的逻辑，就显得冗余了。这一块后面会细讲。
// SQL命令（在解析mybatis-config.xml配置文件的时候生成的）
private final SqlCommand command;
public Object execute(SqlSession sqlSession, Object[] args) {
Object result;
// 从command对象中获取要执行操作的SQL语句的类型，如INSERT/UPDATE/DELETE/SELECT
switch (command.getType()) {
// 插入
case INSERT: {
// 把接口方法里的参数转换成sql能识别的参数
// 如：accountMapper.selectByPrimaryKey(1)
// 把其中的参数"1"转化为sql能够识别的参数
Object param = method.convertArgsToSqlCommandParam(args);
// sqlSession.insert(): 调用SqlSession执行插入操作
// rowCountResult(): 获取SQL语句的执行结果
result = rowCountResult(sqlSession.insert(command.getName(), param));
break;
}
// 更新
case UPDATE: {
Object param = method.convertArgsToSqlCommandParam(args);
// sqlSession.insert(): 调用SqlSession执行更新操作
// rowCountResult(): 获取SQL语句的执行结果
result = rowCountResult(sqlSession.update(command.getName(), param));
break;
}
// 删除
case DELETE: {
Object param = method.convertArgsToSqlCommandParam(args);
// sqlSession.insert(): 调用SqlSession执行更新操作
// rowCountResult(): 获取SQL语句的执行结果
result = rowCountResult(sqlSession.delete(command.getName(), param));
break;
}
// 查询
case SELECT:
// method.returnsVoid(): 返参是否为void
// method.hasResultHandler(): 是否有对应的结果处理器
if (method.returnsVoid() && method.hasResultHandler()) {
executeWithResultHandler(sqlSession, args);
result = null;
} else if (method.returnsMany()) { // 查询多条记录
result = executeForMany(sqlSession, args);
} else if (method.returnsMap()) { // 查询结果返参为Map
result = executeForMap(sqlSession, args);
} else if (method.returnsCursor()) { // 以游标的方式进行查询
result = executeForCursor(sqlSession, args);
} else {
// 参数转换 转成sqlCommand参数
Object param = method.convertArgsToSqlCommandParam(args);
// 执行查询 查询单条数据
result = sqlSession.selectOne(command.getName(), param);
if (method.returnsOptional()
&& (result == null || !method.getReturnType().equals(result.getClass()))) {
result = Optional.ofNullable(result);
}
}
break;
case FLUSH: // 执行清除操作
result = sqlSession.flushStatements();
break;
default:
throw new BindingException("Unknown execution method for: " + command.getName());
}
if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
throw new BindingException("Mapper method '" + command.getName()
+ " attempted to return null from a method with a primitive return type (" + method.getReturnType() + ").");
}
return result;
}
在上面，有多处出现这样一行代码：method.convertArgsToSqlCommandParam(args)，该方法的作用就是将方法参数转换为 SqlCommandParam；具体交由paramNameResolver.getNamedParams() 实现。在看paramNameResolver.getNamedParams()之前，我们先来看下paramNameResolver是什么东西？
public Object convertArgsToSqlCommandParam(Object[] args) {
return paramNameResolver.getNamedParams(args);
}
在前面，我们在实例化MethodSignature对象(new MethodSignature)的时候，在其构造方法中，会实例化ParamNameResolver对象，该对象主要用来处理接口形式的参数，最后会把参数处放在一个map（即属性names）中。map的key为参数的位置，value为参数的名字。
public MethodSignature(Configuration configuration, Class mapperInterface, Method method) {
...
this.paramNameResolver = new ParamNameResolver(configuration, method);
}
对names字段的解释：
假设在xxxMapper中有这么一个接口方法selectByIdAndName()
•selectByIdAndName(@Param("id") String id, @Param("name") String name)转化为map为{{0, "id"}, {1, "name"}}
•selectByIdAndName(String id, String name)转化为map为{{0, "0"}, {1, "1"}}
•selectByIdAndName(int a, RowBounds rb, int b)转化为map为{{0, "0"}, {2, "1"}}
构造方法的会经历如下的步骤
通过反射得到方法的参数类型和方法的参数注解注解，method.getParameterAnnotations()方法返回的是注解的二维数组，每一个方法的参数包含一个注解数组。
遍历所有的参数
-
首先判断这个参数的类型是否是特殊类型,RowBounds和ResultHandler，是的话跳过，咱不处理
-
判断这个参数是否是用来Param注解，如果使用的话name就是Param注解的值，并把name放到map中，键为参数在方法中的位置，value为Param的值
-
如果没有使用Param注解,判断是否开启了UseActualParamName，如果开启了，则使用java8的反射得到方法的名字，此处容易造成异常，
具体原因参考上一篇博文.
- 如果以上条件都不满足的话,则这个参数的名字为参数的下标
// 通用key前缀，因为key有param1，param2，param3等；
public static final String GENERIC_NAME_PREFIX = "param";
// 存放参数的位置和对应的参数名
private final SortedMap names;
// 是否使用@Param注解
private boolean hasParamAnnotation;
public ParamNameResolver(Configuration config, Method method) {
// 通过注解得到方法的参数类型数组
final Class[] paramTypes = method.getParameterTypes();
// 通过反射得到方法的参数注解数组
final Annotation[][] paramAnnotations = method.getParameterAnnotations();
// 用于存储所有参数名的SortedMap对象
final SortedMap map = new TreeMap();
// 参数注解数组长度，即方法入参中有几个地方使用了@Param
// 如selectByIdAndName(@Param("id") String id, @Param("name") String name)中，paramCount=2
int paramCount = paramAnnotations.length;
// 遍历所有的参数
for (int paramIndex = 0; paramIndex < paramCount; paramIndex++) {
// 判断这个参数的类型是否是特殊类型,RowBounds和ResultHandler，是的话跳过
if (isSpecialParameter(paramTypes[paramIndex])) {
continue;
}
String name = null;
for (Annotation annotation : paramAnnotations[paramIndex]) {
// 判断这个参数是否使用了@Param注解
if (annotation instanceof Param) {
// 标记当前方法使用了Param注解
hasParamAnnotation = true;
// 如果使用的话name就是Param注解的值
name = ((Param) annotation).value();
break;
}
}
// 如果经过上面处理，参数名还是null，则说明当前参数没有指定@Param注解
if (name == null) {
// 判断是否开启了UseActualParamName
if (config.isUseActualParamName()) {
// 如果开启了，则使用java8的反射得到该参数对应的属性名
name = getActualParamName(method, paramIndex);
}
// 如果name还是为null
if (name == null) {
// use the parameter index as the name ("0", "1", ...)
// 使用参数在map中的下标作为参数的name，如 ("0", "1", ...)
name = String.valueOf(map.size());
}
}
// 把参数放入到map中，key为参数在方法中的位置，value为参数的name(@Param的value值/参数对应的属性名/参数在map中的位置下标)
map.put(paramIndex, name);
}
// 最后使用Collections工具类的静态方法将结果map变为一个不可修改类型
names = Collections.unmodifiableSortedMap(map);
}
getNamedParams(): 该方法会将参数名和参数值对应起来，并且还会额外保存一份以param开头加参数顺序数字的值
public Object getNamedParams(Object[] args) {
// 这里的names就是ParamNameResolver中的names，在构造ParamNameResolver对象的时候，创建了该Map
// 获取方法参数个数
final int paramCount = names.size();
// 没有参数
if (args == null || paramCount == 0) {
return null;
// 只有一个参数，并且没有使用@Param注解。
} else if (!hasParamAnnotation && paramCount == 1) {
// 直接返回，不做任务处理
return args[names.firstKey()];
} else {
// 包装成ParamMap对象。这个对象继承了HashMap，重写了get方法。
final Map param = new ParamMap();
int i = 0;
// 遍历names中的所有键值对
for (Map.Entry entry : names.entrySet()) {
// 将参数名作为key, 对应的参数值作为value，放入结果param对象中
param.put(entry.getValue(), args[entry.getKey()]);
// 用于添加通用的参数名称，按顺序命名(param1, param2, ...)
final String genericParamName = GENERIC_NAME_PREFIX + (i + 1);
// 确保不覆盖以@Param 命名的参数
if (!names.containsValue(genericParamName)) {
param.put(genericParamName, args[entry.getKey()]);
}
i++;
}
return param;
}
}
}
getNamedParams()总结：
1.当只有一个参数的时候，直接返回，不做任务处理；
2.否则，存入Map中，键值对形式为：paramName=paramValue
•selectByIdAndName(@Param("id") String id, @Param("name") String name)： 传入的参数是["1", "张三"]，最后解析出来的map为：{“id”:”1”,”“name”:”张三”}
•selectByIdAndName(String id, @Param("name") String name)： 传入的参数是["1", "张三"]，最后解析出来的map为：{“param1”:”1”,”“name”:”张三”}
假设执行的SQL语句是select类型，继续往下看代码
在mapperMethod.execute(), 当convertArgsToSqlCommandParam()方法处理完方法参数后，假设我们此时调用的是查询单条记录，那么接下来会执行sqlSession.selectOne()方法。
sqlSession.selectOne()源码分析：
sqlSession.selectOne()也是调的sqlSession.selectList()方法，只不过只返回list中的第一条数据。当list中有多条数据时，抛异常。
@Override
public T selectOne(String statement, Object parameter) {
// 调用当前类的selectList方法
List list = this.selectList(statement, parameter);
if (list.size() == 1) {
return list.get(0);
} else if (list.size() > 1) {
throw new TooManyResultsException("Expected one result (or null) to be returned by selectOne(), but found: " + list.size());
} else {
return null;
}
}
sqlSession.selectList()方法
@Override
public List selectList(String statement, Object parameter) {
return this.selectList(statement, parameter, RowBounds.DEFAULT);
}
继续看：
@Override
public List selectList(String statement, Object parameter, RowBounds rowBounds) {
try {
// 从Configuration里的mappedStatements里根据key(id的全路径)获取MappedStatement对象
MappedStatement ms = configuration.getMappedStatement(statement);
// 调用Executor的实现类BaseExecutor的query()方法
return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
} catch (Exception e) {
throw ExceptionFactory.wrapException("Error querying database. Cause: " + e, e);
} finally {
ErrorContext.instance().reset();
}
}
在sqlSession.selectList()方法中，我们可以看到调用了executor.query()，假设我们开启了二级缓存，那么executor.query()调用的是executor的实现类CachingExecutor中的query()，二级缓存的逻辑就是在CachingExecutor这个类中实现的。
关于mybatis二级缓存：
二级缓存默认是不开启的，需要手动开启二级缓存，实现二级缓存的时候，MyBatis要求返回的POJO必须是可序列化的。缓存中存储的是序列化之后的，所以不同的会话操作对象不会改变缓存。
怎么开启二级缓存：
怎么使用二级缓存？
1.首先肯定是要开启二级缓存啦~
2.除此之外，要使用二级缓存还要满足以下条件：
•当会话提交之后才会填充二级缓存（为什么？后面会解释）
•SQL语句相同，参数相同
•相同的statementID
•RowBounds相同
为什么要会话提交后才会填充二级缓存？
首先，我们知道，与一级缓存（会话级缓存）不同的是，二级缓存是跨线程使用的，也就是多个会话可以一起使用同一个二级缓存。假设现在不用提交便可以填充二级缓存，我们看看会存在什么问题？
假设会话二现在对数据库进行了修改操作，修改完进行了查询操纵，如果不用提交就会填充二级缓存的话，这时候查询操作会把刚才修改的数据填充到二级缓存中，如果此时刚好会话一执行了查询操作，便会查询到二级缓存中的数据。如果会话二最终回滚了刚才的修改操作，那么会话一就相当于发生了脏读。
实际上，查询的时候会填充缓存，只不过此时是填充在暂存区，而不是填充在真正的二级缓存区中。而上面所说的要会话提交后才会填充二级缓存，指的是将暂存区中的缓存刷到真正的二级缓存中。啊？？？那不对呀，填充在暂存区，那此时会话一来查询，岂不是还会从暂存区中取到缓存，从而导致脏读？别急，接着往下看。
对于查询操作，每次取缓存都是从真正的二级缓存中取缓存，而不是从暂存区中取缓存。
好了，我们接着看源码~
CachingExecutor.query()源码：
@Override
public List query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
// 获取要执行的sql语句 sql语句在解析xml的时候就已经解析好了
BoundSql boundSql = ms.getBoundSql(parameterObject);
// 生成二级缓存key
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
// 调用重载方法
return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
调用重载方法：query()
@Override
public List query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
throws SQLException {
// 获取mybatis的二级缓存配置
Cache cache = ms.getCache();
// 如果配置了二级缓存
if (cache != null) {
// 是否要刷新缓存，是否手动设置了需要清空缓存
flushCacheIfRequired(ms);
if (ms.isUseCache() && resultHandler == null) {
ensureNoOutParams(ms, boundSql);
@SuppressWarnings("unchecked")
// 从二级缓存中获取值
List list = (List) tcm.getObject(cache, key);
// 从二级缓存中取不到值
if (list == null) {
// 交由delegate查询 这里的delegate指向的是BaseExecutor
// BaseExecutor中实现了一级缓存的相关逻辑
// 也就是说，当在二级缓存中获取不到值的时候，会从一级缓存中获取，一级缓存要是还是获取不到
// 才会去查询数据库
list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
// 将查询结果存放在暂存区中，只有会话提交后才会将数据刷到二级缓存，避免脏读问题
tcm.putObject(cache, key, list); // issue #578 and #116
}
return list;
}
}
return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
接着，我们看下BaseExecutor.query() 是怎么实现一级缓存逻辑的：
@SuppressWarnings("unchecked")
@Override
public List query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId());
if (closed) {
throw new ExecutorException("Executor was closed.");
}
if (queryStack == 0 && ms.isFlushCacheRequired()) {
clearLocalCache();
}
List list;
try {
queryStack++;
// 尝试从缓存中获取结果 一级缓存
list = resultHandler == null ? (List) localCache.getObject(key) : null;
if (list != null) {
handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
} else {// 从缓存中获取不到结果时
// 从数据库中查询数据
list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
}
} finally {
queryStack--;
}
if (queryStack == 0) { // 回到主查询
// 遍历延迟加载中的数据
for (DeferredLoad deferredLoad : deferredLoads) {
// 把延迟加载的数据加载到结果集中
deferredLoad.load();
}
// issue #601
deferredLoads.clear();
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
// issue #482
clearLocalCache();
}
}
return list;
}
当从一级缓存中获取不到数据时，会查数据库：
调用BaseExecutor.queryFromDatabase()
private List queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
List list;
// 占位符 （解决循环依赖问题）
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
// 执行查询操作
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
} finally {
// 将占位符从缓存中移除
localCache.removeObject(key);
}
// 将查询结果放入到一级缓存中
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {
localOutputParameterCache.putObject(key, parameter);
}
return list;
}
调用BaseExecutor.doQuery()：在BaseExecutor中，doQuery()只是个抽象方法，具体交由子类实现：
protected abstract List doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)
throws SQLException;
从前面的流程中可知，在每次执行CURD的时候，都需要获取SqlSession这个对象，接口如下：
可以看出来这个接口主要定义类关于CRUD、数据库事务、数据库刷新等相关操作。下面看它的默认实现类：
可以看到 DefaultSqlSession 实现了SqlSession中的方法，（其实我们自己也可根据需要去实现）。而在DefaultSqlSession 类中有一个很重要的属性，就是Mybatis的执行器（Executor）。
Executor介绍：
Executor执行器，是mybatis中执行查询的主要代码，Executor分为三种：
•简单执行器SimpleExecutor
•可重用执行器ReuseExecutor
•批量执行器BatchExecutor
默认使用的执行器是SimpleExecutor，可以在mybatis的配置文件中设置使用哪种执行器
public class Configuration {
protected ExecutorType defaultExecutorType = ExecutorType.SIMPLE;
}
Executor类图：
假设我们使用的就是默认的执行器，SimpleExecutor。我们来看下SimpleExecutor.doQuery()
@Override
public List doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
// 这里就进入jdbc了
Statement stmt = null;
try {
// 获取核心配置对象
Configuration configuration = ms.getConfiguration();
StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
//预编译SQL语句
stmt = prepareStatement(handler, ms.getStatementLog());
// 执行查询
return handler.query(stmt, resultHandler);
} finally {
closeStatement(stmt);
}
}
private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
Statement stmt;
// 获取连接 这里的连接是代理连接
Connection connection = getConnection(statementLog);
// 预编译
stmt = handler.prepare(connection, transaction.getTimeout());
// 给预编译sql语句设置参数
handler.parameterize(stmt);
return stmt;
}
在上面的源码中，我们可以看到StatementHandler，它是用来干嘛的？
在mybatis中，通过StatementHandler来处理与JDBC的交互，我们看下StatementHandler的类图：
可以看出，跟Executor的继承实现很像，都有一个Base，Base下面又有几个具体实现子类，很明显，采用了模板模式。不同于CacheExecutor用于二级缓存之类的实际作用，这里的RoutingStatementHandler仅用于维护三个Base子类的创建与调用。
•BaseStatementHandler
•SimpleStatementHandler：JDBC中的Statement接口，处理简单SQL的
•CallableStatementHandler：JDBC中的PreparedStatement，预编译SQL的接口
•PreparedStatementHandler：JDBC中的CallableStatement，用于执行存储过程相关的接口
•RoutingStatementHandler：路由三个Base子类，负责其创建及调用
public RoutingStatementHandler(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {
switch (ms.getStatementType()) {
// 策略模式：根据不同语句类型 选用不同的策略实现类
case STATEMENT:
delegate = new SimpleStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);
break;
case PREPARED:
delegate = new PreparedStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);
break;
case CALLABLE:
delegate = new CallableStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);
break;
default:
throw new ExecutorException("Unknown statement type: " + ms.getStatementType());
}
}
嗯，很眼熟的策略模式，按照statementType的值来决定返回哪种StatementHandler。
那这里的statementType是在哪里赋值的呢？我们看下MappedStatement 的构造方法：
public Builder(Configuration configuration, String id, SqlSource sqlSource, SqlCommandType sqlCommandType) {
...
// 构造方法中默认取值为PREPARED
mappedStatement.statementType = StatementType.PREPARED;
...
}
如果不想使用的StatementType.PREPARED，怎么自定义呢？
SELECT * FROM Student
(2)如果采用的是注解开发：通过@SelectKey的statementType属性指定
@SelectKey(keyProperty = "account",
before = false,
statementType = StatementType.STATEMENT,
statement = "select * from account where id = #{id}",
resultType = Account.class)
Account selectByPrimaryKey(@Param("id") Integer id);
到此，select类型的SQL语句就基本执行完毕了，我们来总结一下mybatis
MyBatis的主要的核心部件有以下几个：
SqlSession： 作为MyBatis工作的主要顶层API，表示和数据库交互的会话，完成必要数据库增删改查功能；
Executor： MyBatis执行器，是MyBatis 调度的核心，负责SQL语句的生成和查询缓存的维护；
StatementHandler： 封装了JDBC Statement操作，负责对JDBC statement 的操作，如设置参数、将Statement结果集转换成List集合。
ParameterHandler： 负责对用户传递的参数转换成JDBC Statement 所需要的参数；
ResultSetHandler： 负责将JDBC返回的ResultSet结果集对象转换成List类型的集合；
TypeHandler： 负责java数据类型和jdbc数据类型之间的映射和转换；
MappedStatement： MappedStatement维护了一条节点的封装；
SqlSource： 负责根据用户传递的parameterObject，动态地生成SQL语句，将信息封装到BoundSql对象中，并返回；
BoundSql： 表示动态生成的SQL语句以及相应的参数信息；
Configuration： MyBatis所有的配置信息都维持在Configuration对象之中；
作者：京东科技 郑志杰
来源：京东云开发者社区 转载请注明来源
