偶尔记一下 - mybatis.io

最初想直接在 mybatis-provider 项目中添加一个 config 包来实现这些功能，也确实这么做的，后来想要拆出来时发现用到了 mybatis-provider 中的代码，又不想拆了，但是最后为了能直接支持 Spring，又不想让 mybatis-provider 中出现 Spring 依赖，终于拆了出来。在开发 1.0.0 的过程中，耗时最多的地方是版本配置的实现，一开始考虑到版本配置文件可以出现在任何地方，因此需要扫描所有位置来找符合规范的配置文件，然后从配置文件中挑选指定的一个配置文件使用

前面的三、四、五各实现一种配置方式，只看到了代码，还没看到具体的使用效果，所以这一篇用一个具体的例子来演示如何使用用户配置和版本配置，通过单元测试来查看用法和效果。我们先回到第一篇中的起因，mybaits-mapper 中不想在每个字段上增加注解，因此底层的 mybatis-provider 项目中增加了 样式，在实体上配置样式后，只要字段符合规则，就不需要加注解配置，没有这个功能前相当于字段名和表名是直接映射的，但是多数情况下，我们都希望字段和列能按照驼峰转下划线方式进行转换，所以这种方式就是新版本的默

作为一个 Java 通用配置管理，想让用户使用更简单，只需要依赖一个模块就行：如果用户运行在 Spring Boot 环境，就让 Spring Boot 相关配置自动生效，不用再增加和 spring 相关的通用配置依赖。想要做到这一点就需要对可选的功能做好隔离，避免因为缺少类无法运行。想集成 Spring 肯定要先添加 Spring 依赖，因为是可选的支持，所以依赖也必须配置为可选：设置 之后，其他项目在依赖 时不会自动引入 spring 依赖，这就避免了依赖传递带来的污染，如果你在有 Sprin

版本配置是提供给模块开发者使用的，模块的使用者可以使用默认的最新版本配置或者通过参数指定要使用的版本配置。模块开发者一般会把配置和代码一起打包，配置文件通常都在 jar 包内，所以需要从 jar 包读取资源，在读取资源时有很多情况需要考虑，如果允许配置文件出现在任意的 jar 包中，就需要对所有 jar 包中的资源进行扫描，就和 Spring 中配置的扫描包一样，指定范围越小，扫描处理越快。综合考虑性能和功能，这里的版本配置中指定了如下的要求：有了上述规则后，就需要确定该使用哪个版本的配置文件。假设项目刚

用户和版本配置都需要读取文件，但是两者的难度相差很大，本节先来看看用户配置的设计和实现。这里的用户配置是一个抽象实现，当具体模块需要使用时需要继承该类进行实现，抽象类中定义了一定的规范和实现，下面先看抽象类的定义：方法说明在当前方法实现的 中，通过 排除了一些字段的获取，在后续又通过加锁方式对用户配置进行初始化，初始化完成后，在从初始化后的 中读取 。在上面抽象类中，有两个抽象方法，这两个方法是用于具体实现的，第一个 方法，用于定义获取配置文件信息的 key，例如返回值可以是 ，用户配置中会通过

本篇内容先选择了最简单的 JVM 和环境变量进行实现，实现过程中可以了解一个简单的规则，SPI 的配置等等，算是复杂实现前的开胃小菜。直接实现前面定义的 接口就可以，系统变量太简单，以至于没有内容可讲：系统变量 JVM 参数方式是目前优先级最高的配置方式，代码中可以看到是 方式读取的，所以在代码中可以通过 进行设置，只要在 前设置了，读取都会有效。除了代码方式外，JVM 真正常用的地方还是在执行代码时，例如 Spring Boot 可执行 Jar 包运行时：假如我们通过系统服务的方式运行 java

有用户提出 mybatis-mapper 能不能不在字段上加这么多注解，很麻烦，陆陆续续有不少用户都提到了这个。最初设计必须加就是为了防止 tk-mapper 中存在的配置问题，都按这种标准去使用，就不会遇到类似下面的问题：为了解决上面的问题，tk-mapper 中有很多对应的配置，大量的配置会使新人上手变的困难。增加配置后，在不同框架中集成时配置方式不同，这又会产生大量配置不生效的问题。mybatis-mapper 中虽然需要大量注解，但是可以通过代码生成器自动生成，如果是全新项目还好说，已有项目想集成，