本篇博客来源于目前编写的一个小插件，简单来说，就是某个库里的某张表里的某条数据被迁移到该表里另一个位置，通过传入两个不同的id来校验迁移是否成功。在这个过程中获取了不少实践知识，概括起来集中在以下两个方面：第一个来自于实现流程，到底该怎样设计才能实现功能。第二个来自于代码：如何调用合适的实现方法（一种是字典，一种是工厂类），如何封装合适的替代类。第三个来自于配置文件：如何编写合适的xml文件，并且解析出来。后续如果博主能接触到更多的设计方式，也会持续更新。
检测数据迁移插件实践
实际场景
两种模式，一种是当作工具使用，这就需要遍历整个库的每张表，在每张表内依据两个用户id来获取两张子表，拿到后进行比较，以此类推，第二种是当作业务操作来做，我想选几条对比就对比几条。目前只做第一种模式的操作。
整体设计
数据范围
对应于两种模式，有不同的数据范围，就得预留不同的方法处理不同的场景。
数据匹配
面临困难1：拿到两张子表后条数和顺序很大概率不同，所以难以对应
解决方案1：获取特征码的方法：
1，通过valueMapping获取映射拼接 id1–id2
2，通过xml配置某些字段为特征，表名和该字段集合特征拼接为特征码 table–字段名集合
面临困难2：表里不一定有Application这个字段
解决方案2：在表里配置关联外键属性，拼接sql作为查询条件。因为每次迁移都针对某一个应用，所以需要应用名——为了使用应用名不同的表采用不同的方式（1，application或者applicationcode这种有类似应用名字段的。2，使用外键和其关联的表） 。将条件当作字符串传进去
数据对比
面临困难：不同字段的对比规则可能不同
解决方案：针对不同字段对比规则不同的问题，可以在配置的时候指定对比规则
具体工作
数据获取层面
写对应的存储过程，得到需要的数据
代码处理层面
1，要封装合适的类来重新封装从数据库中获取的数据，便于使用
2，对应不同的特征码获取方法，要写出通用的方式和各自的实现形式
3，对应于不同的字段匹配规则，要写出通用的方式和各自的实现形式
xml文档编写层面
要设计出符合要求的xml文档，这样才能发挥其匹配的作用
代码编写流程
文件结构设计
主体结构首先设计好，事半功倍。
1，首先考虑我需要有不同的匹配规则，所以我需要有匹配规则的接口和实现类，我还有不同的创建特征码的方式，所以也需要对应的接口和实现类。
2，考虑实体设计，我需要从库，表，字段三种不同级别创建对比信息结果封装类，为了重新封装数据表，我又需要准备重新封装的类，还有一个就是传入参数的一个封装（这里说一下，对于有可能变化的传入参数，不如把这几个参数封装成类，这样扩展起来非常方便）
3，除了编写xml文件，当然xml解析类也是必不可少的了，把它放到配置文件夹里
4，当然，最核心的就是对外服务提供类
5，正如前几篇提到的，测试驱动开发，测试类入口当然要提前准备好
核心流程
这里不再赘述配置文件，配置文件解析类，等代码的编写，主要讲下核心的流程如何走
主体部分不涉及任何逻辑结构，细分功能都调用辅助方法来实现这是我此次代码编写中得出的最大的结论，这样可以让你迅速把握主体，不会太乱。而辅助方法也按照主体的调用顺序按顺序编写，这样能让代码清晰，阅读体验非常好
