CSDN_LiMingfly的博客

有张原始表tschedule 和新表bjcodechange ，需要将原始表的compeny_code字段和bjcodechange 的oldwindcode 进行关联替换成bjcodechange表的newwindcode字段。但是有特殊字符的数据如下 注意测试原始表的compeny_code字段的内容许如下所示。由于本人sql比较薄弱 将一些常用又使用的sql语句记录与大家分享。步骤1：拆分后的中间数据 (split_data)无特殊字符的查询很简单 如下。

当把 selectKey 解析完成以后，也是像解析其他类型的标签一样，按照 MappedStatement 映射器语句存放到 Configuration 配置项中，这样后面执行 DefaultSqlSession 获取 SQL 的时候就可以从配置项获取了，并在执行器中完成 SQL 的操作。是在原有的 Mapper XML 对各类标签语句的解析中，对 insert 操作进行扩展，添加新的标签 selectKey 并通过这样一个标签的解析、执行、封装处理把最终的插入索引结果返回到入参对象的对应属性字段上。

那么这里就有一个问题了，我们在使用 Mybatis 框架的时候，如果遇到这样的字段，则需要通过把数据库表中的下划线的字段名称，映射成 Java 代码中的驼峰字段，这样才能在执行查询操作的时候，正确的把数据库中的结果映射到 Java 代码的返回对象上。所有的解析操作完成以后就是到了接触处理封装中，这里你可以思考怎么把 SQL 执行的结果和对象封装到一起，普通的对象默认按照对象字段即可封装，而带有下划线的属性字段，则需要根据映射的2个字段，下划线对应非下划线的方式，进行匹配处理。最终返回统一的封装对象结果。

可能领导也都觉得可能就是码农不爱说话，其实不爱说话是一方面，但还有另外一方面是有些领导对于码农提出的问题，给出的回复往往是：“你提出这个问题，你就要给出这个问题的解决办法！所以不同的岗位要执行各自的职责，无论领导、产品、研发、测试、业务，都应该环环相扣，各司其职，不过分包装结果，正确看待问题。才可能做出像苹果那样的优秀产品，而不是那么割裂的独立功能。目标。

目前这个框架中所提供的 SQL 处理仅有一个 select 查询操作，还没有其他我们日常常用的 insert、update、delete，以及 select 查询返回的集合类型数据。其实这一部分新增处理 SQL 的内容，也就是在 SqlSession 需要定义新的接口，通知让这些接口被映射器类方法 MapperMethod 进行调用处理。

1：在流程上，通过 DefaultSqlSession#selectOne 方法调用执行器，并通过预处理语句处理器 PreparedStatementHandler 执行参数设置和结果查询。2：那么这个流程中我们所处理的参数信息，也就是每个 SQL 执行时，那些?号 需要被替换的地方，目前是通过硬编码的方式进行处理的。而这就是本章节需要解决的问题，如果只是硬编码完成参数设置，那么对于所有哪些不同类型的参数就没法进行操作了。

实现到本章节前，关于 Mybatis ORM 框架的大部分核心结构已经逐步体现出来了，包括；解析、绑定、映射、事务、执行、数据源等。但随着更多功能的逐步完善，我们需要对模块内的实现进行细化处理，而不单单只是完成功能逻辑。这就有点像把 CRUD 使用设计原则进行拆分解耦，满足代码的易维护和可扩展性。而这里我们首先着手要处理的就是关于 XML 解析的问题，把之前粗糙的实现进行细化，满足我们对解析时一些参数的整合和处理。

但在实操上，很多码农根本没法阅读框架源码。首先一个非常大的问题是，面对如此庞大的框架源码，不知道从哪下手。与平常的业务需求开发相比，框架源码中运用了大量的设计原则和设计模式对系统功能进行解耦和实现，也使用了不少如反射、代理、字节码等相关技术。如果你有阅读 Mybatis 的源码，会发现这里使用了 Mybatis 自己实现的元对象反射工具类，可以完成一个对象的属性的反射填充。这块的工具类叫做 MetaObject 并提供相应的；

所有系统的设计和实现，核心都在于如何解耦，如果解耦不清晰最后直接导致的就是再继续迭代功能时，会让整个系统的实现越来越臃肿，稳定性越来越差。而关于解耦的实践在各类框架的源码中都有非常不错的设计实现，所以阅读这部分源码，就是在吸收成功的经验。把解耦的思想逐步运用到实际的业务开发中，才会让我们写出更加优秀的代码结构。设计。

在上一章节我们解析了 XML 中数据源配置信息，并使用 Druid 创建数据源完成数据库的操作。但其实在 Mybatis 中是有自己的数据源实现的，包括无池化的 UnpooledDataSource 实现方式和有池化的 PooledDataSource 实现方式。你可以把池化技术理解为享元模式的具体实现方案，通常我们对一些需要较高创建成本且高频使用的资源，需要进行缓存或者也称预热处理。并把这些资源存放到一个预热池子中，需要用的时候从池子中获取，使用完毕再进行使用。

在上一章节我们解析 XML 中的 SQL 配置信息，并在代理对象调用 DefaultSqlSession 中进行获取和打印操作，从整个框架结构来看我们解决了对象的代理、Mapper的映射、SQL的初步解析，那么接下来就应该是连库和执行SQL语句并返回结果了。那么这部分内容就会涉及到解析 XML 中关于 dataSource 数据源信息配置，并简历事务管理和连接池的启动和使用。并将这部分能力在 DefaultSqlSession 执行 SQL 语句时进行调用。核心类图如下。

你是怎么面对功能迭代的？很多程序员在刚开始做编程或者新加入一家公司时，都没有多少机会可以做一个新项目，大部分时候都是在老项目上不断的迭代更新。在这个过程你可能要学习N个前人留下的各式各样的风格迥异的代码片段，在这些纵横交错的流程中，找到一席之地，把自己的ifelse加进去。但说回来，其实不能逐步清理一片屎山，让代码在你的手上逐步清晰、整洁、干净，很多时候也是作为码农自身经验的不足，不懂得系统重构、不了解设计原则、不熟悉业务背景、不清楚产品走向等等原因造成的。

其实对于解决这类复杂的项目问题，核心在于要将主干问题点缩小，具体的手段包括：分治、抽象和知识。运用设计模式和设计原则等相关知识，把问题空间合理切割为若干子问题，问题越小也就越容易理解和处理。就像你可以把很多内容做成单个独立的案例一样，最终在进行聚合使用。上一节编码存在两问题1：需要编码告知 MapperProxyFactory 要对哪个接口进行代理。2：需要自己编写一个假的 SqlSession 处理实际调用接口时的返回结果。所以我们来解决上述存在问题。