MyBatis框架 第4章 MyBatis 映射文件
第4章 MyBatis 映射文件
4.1 Mybatis映射文件简介
1) MyBatis 的真正强大在于它的映射语句，也是它的魔力所在。由于它的异常强大，映射器的 XML 文件就显得相对简单。如果拿它跟具有相同功能的 JDBC 代码进行对比，
2) SQL 映射文件有很少的几个顶级元素（按照它们应该被定义的顺序）：
cache – 给定命名空间的缓存配置。
cache-ref – 其他命名空间缓存配置的引用。
resultMap – 是最复杂也是最强大的元素，用来描述如何从数据库结果集中来加 载对象。
parameterMap – 已废弃！老式风格的参数映射。内联参数是首选,这个元素可能 在将来被移除，这里不会记录。
sql – 可被其他语句引用的可重用语句块。
insert – 映射插入语句
update – 映射更新语句
delete – 映射删除语句
select – 映射查询语
你会立即发现省掉了将近 95% 的代码。MyBatis 就是针对 SQL 构建的，并且比普通的方法做的更好。
4.2 Mybatis使用insert|update|delete|select完成CRUD
4.2.1 select
4.2.2 insert
4.3 主键生成方式、获取主键值
4.3.1 主键生成方式
1) 支持主键自增，例如MySQL数据库
2) 不支持主键自增，例如Oracle数据库
4.3.2 获取主键值
1) 若数据库支持自动生成主键的字段（比如 MySQL 和 SQL Server），则可以设置 useGeneratedKeys=”true”，然后再把 keyProperty 设置到目标属性上。
2) 而对于不支持自增型主键的数据库（例如 Oracle），则可以使用 selectKey 子元素：selectKey 元素将会首先运行，id 会被设置，然后插入语句会被调用
4.4 参数传递
4.4.1 参数传递的方式
1) 单个参数
可以接受基本类型，对象类型。这种情况MyBatis可直接使用这个参数，不需要经过任 何处理。
2) 多个参数
任意多个参数，都会被MyBatis重新包装成一个Map传入。Map的key是param1，param2，或者0，1…，值就是参数的值
3) 命名参数
为参数使用@Param起一个名字，MyBatis就会将这些参数封装进map中，key就是我们自己指定的名字
4) POJO
当这些参数属于我们业务POJO时，我们直接传递POJO
5) Map
我们也可以封装多个参数为map，直接传递
6) Collection/Array
会被MyBatis封装成一个map传入, Collection对应的key是collection,Array对应的key是array. 如果确定是List集合，key还可以是list.
4.4.2 参数传递源码分析
4.4.3 参数处理
1) 参数位置支持的属性:
javaType、jdbcType、mode、numericScale、resultMap、typeHandler、jdbcTypeName、expression
2) 实际上通常被设置的是：可能为空的列名指定 jdbcType ,例如:
4.4.4 参数的获取方式
1) #{key}：获取参数的值，预编译到SQL中。安全。
2) ${key}：获取参数的值，拼接到SQL中。有SQL注入问题。ORDER BY ${name}
4.5 select查询的几种情况
4.6 resultType自动映射
1) autoMappingBehavior默认是PARTIAL，开启自动映射的功能。唯一的要求是列名和javaBean属性名一致
2) 如果autoMappingBehavior设置为null则会取消自动映射
3) 数据库字段命名规范，POJO属性符合驼峰命名法，如A_COLUMNàaColumn，我们可以开启自动驼峰命名规则映射功能，mapUnderscoreToCamelCase=true
4.7 resultMap自定义映射
1) 自定义resultMap，实现高级结果集映射
2) id ：用于完成主键值的映射
3) result ：用于完成普通列的映射
4) association ：一个复杂的类型关联;许多结果将包成这种类型
5) collection ： 复杂类型的集
4.7.1 id&result 
4.7.2 association
1) POJO中的属性可能会是一个对象,我们可以使用联合查询，并以级联属性的方式封装对象.使用association标签定义对象的封装规则
2) 使用级联的方式:
4.7.3 association 分步查询
1) 实际的开发中，对于每个实体类都应该有具体的增删改查方法，也就是DAO层， 因此
对于查询员工信息并且将对应的部门信息也查询出来的需求，就可以通过分步的方式
完成查询。
- 先通过员工的id查询员工信息
- 再通过查询出来的员工信息中的外键(部门id)查询对应的部门信息.
4.7.4 association 分步查询使用延迟加载
1) 在分步查询的基础上，可以使用延迟加载来提升查询的效率，只需要在全局的
Settings中进行如下的配置:
4.7.5 collection
1) POJO中的属性可能会是一个集合对象,我们可以使用联合查询，并以级联属性的方式封装对象.使用collection标签定义对象的封装规则
2) Collection
4.7.6 collection 分步查询
1) 实际的开发中，对于每个实体类都应该有具体的增删改查方法，也就是DAO层， 因此
对于查询部门信息并且将对应的所有的员工信息也查询出来的需求，就可以通过分步的方式完成查询。
- 先通过部门的id查询部门信息
- 再通过部门id作为员工的外键查询对应的部门信息.
4.7.7 collection 分步查询使用延迟加载
4.7.8 扩展: 分步查询多列值的传递
1) 如果分步查询时，需要传递给调用的查询中多个参数，则需要将多个参数封装成
Map来进行传递，语法如下: {k1=v1, k2=v2....}
2) 在所调用的查询方，取值时就要参考Map的取值方式，需要严格的按照封装map
时所用的key来取值.
4.7.9 扩展: association 或 collection的 fetchType属性
1) 在<association> 和<collection>标签中都可以设置fetchType，指定本次查询是否要使用延迟加载。默认为 fetchType=”lazy” ,如果本次的查询不想使用延迟加载，则可设置为
fetchType=”eager”.
2) fetchType可以灵活的设置查询是否需要使用延迟加载，而不需要因为某个查询不想使用延迟加载将全局的延迟加载设置关闭.
