在第一节中我们看到了Mybatis的部分配置信息,这些信息是基础信息,足以先将Mybatis拿来玩弄一下,
但是在把玩一番之后,我们知道了Mybatis的基本使用方法,但是对于配置文件的详细信息和结果映射、动态Sql
等好东西并没有好好研究,下面几节将一一进行介绍。
MyBatis 的配置文件包含了会深深影响 MyBatis 行为的设置和属性信息。 配置文档的顶层结构如下:
- configuration(配置)
- properties(属性)
- settings(设置)
- typeAliases(类型别名)
- typeHandlers(类型处理器)
- objectFactory(对象工厂)
- plugins(插件)
- environments(环境配置)
- environment(环境变量)
- transactionManager(事务管理器)
- dataSource(数据源)
- databaseIdProvider(数据库厂商标识)
- mappers(映射器)
配置文件结构
1 |
|
注意:这个配置文件的标签元素是有顺序的,需要按顺序配置。如下:
1 | configuration: |
我们回头看第一节中的配置文件也可以看出这个顺序,虽然其中有一些没有配置。
properties
db.properties:
1 | com.mysql.jdbc.Driver = |
properties标签:
1 | <!--引入properties的属性文件--> |
我们可以直接读取文件,也可以补充属性文件中没有的属性。
如果属性在不只一个地方进行了配置,那么 MyBatis 将按照下面的顺序来加载:
- 在 properties 元素体内指定的属性首先被读取。
- 然后根据 properties 元素中的 resource 属性读取类路径下属性文件或根据 url 属性指定的路径读取属性文件,并覆盖已读取的同名属性。
- 最后读取作为方法参数传递的属性,并覆盖已读取的同名属性。
因此,通过方法参数传递的属性具有最高优先级,resource/url 属性中指定的配置文件次之,最低优先级的是 properties 属性中指定的属性。
settings
1 | <!--设置使用驼峰命名--> |
settings一般是一些配置,所以我们看一下官网的介绍:
一个配置完整的 settings 元素的示例如下:
1 | <settings> |
typeAliases
类型别名就是为Java类型设置一个短的名字。它只和XML配置相关,存在的意义仅在于用来减少类全限定名的冗余。例如:
1 | <typeAliases> |
如上所述配置计较麻烦,我们可以配置一个包,让其所有都遵循这个规则:
1 | <!--设置别名--> |
我们还可以在此基础上使用注解修改默认取的别名:
1 | "card") ( |
这是一些为常见的 Java 类型内建的相应的类型别名。它们都是不区分大小写的,注意对基本类型名称重复采取的特殊命名风格。
别名 | 映射的类型 |
---|---|
_byte | byte |
_long | long |
_short | short |
_int | int |
_integer | int |
_double | double |
_float | float |
_boolean | boolean |
string | String |
byte | Byte |
long | Long |
short | Short |
int | Integer |
integer | Integer |
double | Double |
float | Float |
boolean | Boolean |
date | Date |
decimal | BigDecimal |
bigdecimal | BigDecimal |
object | Object |
map | Map |
hashmap | HashMap |
list | List |
arraylist | ArrayList |
collection | Collection |
iterator | Iterator |
environments
MyBatis 可以配置成适应多种环境,这种机制有助于将 SQL 映射应用于多种数据库之中, 现实情况下有多种理由需要这么做。例如,开发、测试和生产环境需要有不同的配置;或者想在具有相同 Schema 的多个生产数据库中 使用相同的 SQL 映射。有许多类似的使用场景。
不过要记住:尽管可以配置多个环境,但每个 SqlSessionFactory 实例只能选择一种环境。
所以,如果你想连接两个数据库,就需要创建两个 SqlSessionFactory 实例,每个数据库对应一个。而如果是三个数据库,就需要三个实例,依此类推,记起来很简单:
环境元素定义了如何配置环境:
1 | <!--配置环境--> |
这里关键的点:
- 默认使用的环境ID(比如:default=”development”)
- 每个environment元素定义的环境ID(比如:id=”development”)
- 事务管理器的配置(比如:type=”JDBC”)
- 数据源的配置(比如:type=”POOLED”)
默认的环境和环境 ID 是自解释的,因此一目了然。 你可以对环境随意命名,但一定要保证默认的环境 ID 要匹配其中一个环境 ID。
事务管理器(TransactionManager)
在Mybatis中有两种类型的事务管理器(也就是type=”[JDBC|MANAGED]”):
JDBC - 这个配置就是直接使用了JDBC的提交和回滚设置,它依赖于从数据源得到的连接来管理事务作用域
MANAGED - 这个配置几乎没做什么。它从来不提交或回滚一个连接,而是让容器来管理事务的整个生命周期(比如 JEE 应用服务器的上下文)。 默认情况下它会关闭连接,然而一些容器并不希望这样,因此需要将 closeConnection 属性设置为 false 来阻止它默认的关闭行为。例如:
1
2
3<transactionManager type="MANAGED">
<property name="closeConnection" value="false"/>
</transactionManager>提示:如果你正在使用 Spring + MyBatis,则没有必要配置事务管理器, 因为 Spring 模块会使用自带的管理器来覆盖前面的配置。
数据源(dataSource)
dataSource 元素使用标准的 JDBC 数据源接口来配置 JDBC 连接对象的资源。
- 许多 MyBatis 的应用程序会按示例中的例子来配置数据源。虽然这是可选的,但为了使用延迟加载,数据源是必须配置的。
有三种内建的数据源类型(也就是 type=”[UNPOOLED|POOLED|JNDI]”):
- UNPOOLED 这个数据源的实现只是每次被请求时打开和关闭连接。虽然有点慢,但对于在数据库连接可用性方面没有太高要求的简单应用程序来说,是一个很好的选择。 不同的数据库在性能方面的表现也是不一样的,对于某些数据库来说,使用连接池并不重要,这个配置就很适合这种情形
- driver – 这是 JDBC 驱动的 Java 类的完全限定名(并不是 JDBC 驱动中可能包含的数据源类)。
- url – 这是数据库的 JDBC URL 地址。
- username – 登录数据库的用户名。
- password – 登录数据库的密码。
- defaultTransactionIsolationLevel – 默认的连接事务隔离级别。
- POOLED– 这种数据源的实现利用“池”的概念将 JDBC 连接对象组织起来,避免了创建新的连接实例时所必需的初始化和认证时间。 这是一种使得并发 Web 应用快速响应请求的流行处理方式
- JNDI – 这个数据源的实现是为了能在如 EJB 或应用服务器这类容器中使用,容器可以集中或在外部配置数据源,然后放置一个 JNDI 上下文的引用
mappers
既然 MyBatis 的行为已经由上述元素配置完了,我们现在就要定义 SQL 映射语句了。 但是首先我们需要告诉 MyBatis 到哪里去找到这些语句。 Java 在自动查找这方面没有提供一个很好的方法,所以最佳的方式是告诉 MyBatis 到哪里去找映射文件。 你可以使用相对于类路径的资源引用, 或完全限定资源定位符(包括 file:/// 的 URL),或类名和包名等。例如:
1 | <!--mapper xml文件--> |
1 | <!-- 使用完全限定资源定位符(URL) --> |
总结:这节主要介绍一下Mybatis的全局配置文件中的常见配置,如果需要完整了解的可以参考官方文档。
源码地址:
https://gitee.com/ooyhao/JavaRepo_Public/tree/master/Mybatis