根据源代码修改XSD文件

这两天遇到了一个问题&＃xff0c;就是以前的公司的VB代码是根据XSD文件自动生成的&＃xff0c;然后呢&＃xff0c;这个XSD文件被修改了&＃xff08;这就有点尴尬了&＃xff09;&＃xff0c;以后代码也要更加XSD文件进行生成&＃xff0c;这个时候如果人工修改的话&＃xff0c;那成本和时间也太高了&＃xff0c;这个时候就只能写个工具去做这个事情了&＃xff0c;省时省力。辛亏原来的代码是和数据库对接的&＃xff0c;虽然文件多&＃xff0c;代码量大&＃xff0c;但是文件的结构是统一的。我选择Java进行这个工具的开发&＃xff0c;主要我也是学习Java平台的。

首先得考虑的是如何解析XSD文件的问题。在Java中&＃xff0c;对XML文件的解析主要是有四种方式&＃xff1a;DOM&＃xff0c;SAX&＃xff0c;JDOM&＃xff0c;DOM4J。每个方式都有各自的优缺点&＃xff0c;我最后考虑选择使用的是DOM的标准实现&＃xff0c;主要是因为访问是双向的&＃xff0c;可以在任何时候对树上下导航&＃xff0c;获取和操作任意部分的数据。其他性能什么的还不是主要考虑的需求&＃xff0c;因为不知道XSD中和VB源代码对应的代码中在什么地方&＃xff0c;所以要直接就能再任意时刻对XSD的文件进行访问。

还有一个需要考虑的是XSD文件的命名空间的问题&＃xff0c;没有命名空间的XML文件解析十分方便&＃xff0c;但是存在命名空间的XSD文件解析优点麻烦&＃xff0c;但是DOM可以直接获取到命名空间中最特殊的元素的位置&＃xff0c;这就为定位需要修改的地方提供了较大的便利性。

看到是源代码&＃xff0c;我们的第一反应应该是通过编译原理中讲的方式&＃xff0c;对源代码进行整体分析&＃xff0c;然后再进行处理。其实没有那个必要&＃xff0c;原来的代码是通过代码生成器生成出来的&＃xff0c;其本身就有一定的规律&＃xff0c;找到这些规律之后&＃xff0c;其实发现更加简单。

通过源码发现在如下语句之后"Public Class "加上对于的表名之后&＃xff0c;下面的函数就是我们需要的内容了&＃xff0c;再匹配”Public Property “加上行的名称&＃xff0c;精确到一对一相对的关系&＃xff0c;在对其中的数据进行提取&＃xff0c;和XSD文件中每一个节点的属性进行对比后修改就行了。

这样&＃xff0c;我们就完美的避开了需要对整个文件进行分析完之后才能进行匹配的坑了&＃xff0c;虽然效果上肯定是进行分析后的好&＃xff0c;但是我这种设计所造成的时间损耗还是在接受范围内的&＃xff0c;并且开发的要求也不高。

方法设计

1. 读取待匹配文件夹下的所有文件的名称&＃xff0c;因为VB源代码和XSD文件的名称是一一对应的
2. 通过名称找到相关的XSD文件
3. 获取XSD文件中的相关信息
   1. 通过document.getElementsByTagName获取节点列表&＃xff0c;当然我找的这元素有点特殊&＃xff0c;其在XSD文中是唯一的&＃xff0c;这个便利性就特别大了
   2. 获取当前DOM的实例
   3. 获取所有子节点的列表
   4. 对于每一个子节点的信息与VB中的信息匹配进行修改
4. 获取VB中的信息
   1. 读取VB文件到Buffer中
   2. 按行进行读取&＃xff0c;直达匹配到类级别
   3. 对此继续往下读&＃xff0c;匹配到配置的信息
   4. 获取这个函数中的信息
   5. 通过正则表达式获取其中的信息
5. 保存修改好的XSD到新的文件中
6. 关闭各种流

其实关键的东西没有多少&＃xff0c;剩下的东西就是编码了&＃xff0c;其实分析源代码有时候不一定要进行完整的分析&＃xff0c;其实可以将其看成是对一个文件中的数据进行读取和分析&＃xff0c;根据实际的需要和要求选择自己需要的技术就可以了&＃xff0c;不一定要一尘不变。如匹配到类和方法的时候&＃xff0c;我就发现正则是匹配方式不好&＃xff0c;所有直接使用按为匹配的方式&＃xff0c;而提取数据的时候正则的优势就表现出来了&＃xff0c;所有根据环境选择东西&＃xff0c;也有可能是我没有完全对正则理解透的原因。