SpringBoot mybatis-starter解析

MybatisStarter详解:自动配置、注解应用与Mapper管理
本文介绍了mybatis-starter的使用指南,包括自动检测DataSource、SqlSessionFactory和SqlSessionTemplate的创建,注解类的引入,以及MybatisAutoConfiguration、DataSourceAutoConfiguration和MybatisLanguageDriverAutoConfiguration的作用。还涵盖了配置类源码解析、Mapper类扫描和执行的关键环节。

mybatis-starter使用指南

  • 自动检测工程中的DataSource
  • 创建并注册SqlSessionFactory实例
  • 创建并注册SqlSessionTemplate实例
  • 自动扫描mappers

mybatis-starter原理解析

注解类引入原理

查看对应的autoconfigure

MybatisLanguageDriverAutoConfiguration 主要是协助使用注解来配置SQL语句的

@Configuration: 标志为配置类

@ConditionalOnClass@ConditionalOnSingleCandidate都是生效条件: SqlSessionFactory.class ,SqlSessionFactoryBean.class, DataSource.class

@EnableConfigurationProperties: 使mybatis前缀的properties的配置生效

@AutoConfigureAfter:

  • 保证在DataSourceAutoConfiguration.classMybatisLanguageDriverAutoConfiguration.class两个配置类之后生效
  • DataSourceAutoConfiguration: 对数据源做配置
  • MybatisLanguageDriverAutoConfiguration: 主要是协助使用注解来配置SQL语句的

MybatisAutoConfiguration 的主要作用是注入两个Bean: SqlSessionFactorySqlSessionTemplate

配置类源码解析

关键类注入

Mapper类扫描

Mapper类生成

Mapper类执行

### 关于 `mybatis-spring-boot-starter` 的依赖冲突解决方案 在 Spring Boot 项目中,当引入 `mybatis-spring-boot-starter` 后发生依赖冲突或配置问题时,通常是因为多个版本的 MyBatis 或其相关组件(如 MyBatis-SpringSpring Boot 自身的核心库)之间不兼容所导致。以下是针对此类问题的具体分析和解决方案。 #### 1. **依赖冲突的原因** MyBatis-Spring-Boot-Starter 是一个专门用于简化 MyBatisSpring Boot 集成的 Starter 包[^4]。它会自动导入必要的依赖项并完成基础配置,例如创建 `SqlSessionFactory` 实例以及扫描 Mapper 接口。然而,在某些情况下,如果项目的其他部分也显式声明了类似的依赖,则可能导致重复加载或者版本冲突的情况。具体来说: - 如果手动指定了较低版本的 MyBatis 或者 MyBatis-Spring 库,而这些库又与当前使用的 MyBatis-Spring-Boot-Starter 所需的版本不符,则会出现运行错误。 - 当存在多处定义相同功能模块(比如另一个框架同样提供了 SQL Session Factory 创建逻辑),则可能引发 Bean 定义覆盖等问题。 #### 2. **排查方法** 为了定位具体的冲突源,可以采用以下几种方式来诊断问题所在: ##### (a) 使用 Maven Dependency Tree 查看实际解析到的依赖树 通过执行命令 `mvn dependency:tree | grep mybatis` 可以查看整个工程里所有关于 MyBatis 的依赖关系及其最终选定的版本号。这有助于发现是否有意料之外的老版或其他分支路径上的干扰因素被拉进来。 ##### (b) 检查是否存在多余的自定义配置类 有时开发者可能会因为习惯原因额外编写了一些原本由 MyBatis-Spring-Boot-Starter 自动生成的内容,例如重新注册了一个新的 `DataSourceTransactionManager` 豆子实例等操作。这种做法容易引起不必要的复杂性和潜在矛盾点。 #### 3. **解决策略** 基于上述分析结果采取相应措施消除隐患: ##### 方法一:统一管理 BOM 文件中的版本控制信息 推荐利用官方发布的 Bill Of Materials(BOM),即物料清单文件来进行全局性的协调工作。对于 MyBatis 来说就是添加如下片段至 pom.xml 中: ```xml <dependencyManagement> <dependencies> <!-- 引入 MyBatis BOM --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-bom</artifactId> <version>${mybatis.version}</version> <type>pom</type> <scope>import</scope> </dependency> <!-- 引入 Spring Boot 特定扩展 bom --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>${spring-boot-version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ``` 这样做的好处是可以让所有的直接/间接引用都遵循同一个标准体系下的约束条件,从而减少因局部调整带来的不确定性风险。 ##### 方法二:排除不需要的部分 假如确认确实只需要保留单一实现形式的话,可以直接修改 POM 文件里的描述去掉那些冗余条目。例如下面的例子展示了如何强制移除掉默认附带的一些特性选项: ```xml <!-- 显式指定只使用 core 功能集而不包含 extra plugins 等附加物 --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <exclusions> <exclusion> <groupId>*</groupId><!-- 替代符匹配任意值 --> <artifactId>*</artifactId> </exclusion> </exclusions> </dependency> ``` 注意这里的星号(*)表示通配任何特定名称的空间范围;当然也可以替换为确切的目标对象列表以便更加精确地筛选目标。 ##### 方法三:升级至最新稳定发行版 考虑到软件开发领域技术更新迭代较快的特点,适时跟进最新的发布成果往往能够有效规避很多已知缺陷的影响。因此建议定期查阅官方文档获取最前沿的支持状态,并及时迁移到适配良好的组合搭配之中去尝试解决问题。 --- ```java // 示例代码展示如何正确注入Mapper接口 @Autowired private UserMapper userMapper; public List<User> getAllUsers() { return this.userMapper.selectAll(); } ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值