1.概述
我们要将外部系统给的XML文件进行解析，并存入到数据库。
但是我们并没有DTD或者Schema，只有一个WORD格式的说明文档；更离谱的是，XML结点树的结构(即XML结点与XML结点之间的关系)与业务Bean树的结构(即业务Bean与业务Bean的关系)并不完全一致，比如说，从业务角度讲，一只猪有只猪头，而在XML里，却写成了 pig --content --pighead 的三级关系，无端端多了一个content结点！ 没有DTD/Schema，结构又不规范，我们就没法用自动化的第三方JAVA转换API进行解析，而只能手动地、一个一个地解析。但在手动解析的过程中，我们仍然发现各个结点的解析和入库中有很多东西是共同的，或者有共同的规律，这些东西可以抽出来作为一个准框架，然后再将结点中不同的部分开放出来，允许具体的结点做具体的实现，并最终形成一个半自动的解析/入库框架。
为什么说它是半自动的？它有哪些限制？
自动：不必为每个结点编写XML 解析代码和入库代码
“半”：需手动地编写每个JAVABEAN，并手动地为每个BEAN建表
限制：
a.所有业务字段的类型只能设为STRING/VARCHAR，并且非业务字段的类型在BEAN中不能为STRING
b.BEAN名与表名必须相同，或者可以进行一对一映射
c.BEAN的成员变量名必须与XML结点的属性名/元素名相同，或者可以进行一对一映射
这三种限制都是利用JAVA反射机制进行自动操作的前提。
2.基本思想
所谓的XML解析，就是将XML结点转换成JAVABEAN实例，XML结点的ATTRIBUTE值和ELEMENT值就是JAVABEAN实例的成员变量值; 所谓的持久化，就是将JAVABEAN实例变成数据库对应表中的一条记录，JAVABEAN实例的成员变量值就是记录中某个字段的值，或者其他表中某个参考了该记录的另一条记录。
而在XML中，JAVABEAN体系中，数据据表关系结构中，结点和结点之间的关系都是树形的关系。整体的解析和入库，就是在遍历树时执行转换动作。而我们知道，树的遍历是可以用递归算法实现的，而递归，就不用说了吧，它是实现程序“自动化”的主要途径之一。
以下是对各“树”的具体分析：
假设两个业务实体A和B之间存在聚合关系(父子关系)。那么具体可分三种情况：
a.B是一个原子字段（即不可再分），并且是A的一个属性。
XML中，B是A的XML ATTRIBUTE或者A的原子ELEMENT
BEAN中，B是A的成员变量，并且B是一个JAVA内置的数据类型
数据库中，B是A表的一个列
b.B是一个复合字段，并且是A的一个属性，而且和A是1:1关系
XML中，B是A的ELEMENT，并且B有自己的ELEMENT或者ATTRIBUTE
BEAN中，B是A的成员变量，并且程序中有个B类
数据库中，B表是A表的子表(即B外键参考了A表)
c.B是一个复合字段，并且是A的一个属性，而且和A是N:1关系
XML中，B是A的ELEMENT，并且B有自己的ELEMENT或者ATTRIBUTE
BEAN中，B组成一个类集（List,Set）共同作为A的成员变量，并且程序中有个B类
数据库中，B表是A表的子表(即B外键参考了A表)
了解了这三种情况，接下来就好办了。程序每抓到一个结点，都要递归地进行以下处理：先处理它的原子属性（情形a），接着处理它的单个子结点（情形b），最后处理它的类集子结点( 情形c)。
3.代码实现的重点
两个重点：
a.如何让业务实体在三棵树内一一对应好？
b.如何发现树形关系，比如A的属性有哪些，A的子结点有哪些？
问题a很简单，就是让三棵树里相同的业务实体取相同的名字。
a.解析XML时发现 结点X 的 属性Y 等于 值Z，则执行PropertyUtils.setProperty(结点X , 属性Y , 值Z)即可。在这里X，Y,Z是变量，程序不用关心具体的结点和属性是哪些个。需要注意的是，如果属性Y是原子字段，则要求属性Y必须为String类型，否则程序不知道将值Z转换成哪种类型（注：关于PropertyUtils， 请见apache commons Beanutils ）
b.入库时发现x.getY()=z。如果属性y是原子字段，则执行SQL insert into X(...,y,...) values (...,z,...)，这里要求y字段必须为varchar/char类型， 以免发生类型转换错误.
关于问题b
XML树：JDOM, dom4j等都可以直接找到父子关系
BEAN体系：
I.原子属性。我们限定一个BEAN中所有有业务意义的原子字段的类型都STRING，所有String类型的字段都是业务字段
II.单个子结点。我们让所有有业务意义的非原子字段都实现一个共同的接口BusiNode，这样一个BEAN中所有BusiNode成员都是这个BEAN的子结点
III.类集子结点。我们也可以限定所有且只有类集子结点可以使用List或Set类型，这样可以利用过滤出所有类集子结点。然而，在JAVA1.4及以前的版本里，程序并不知道过滤出的类集子结点是哪个Class的实例（因为没有泛型），也就没办法实例化一个类集子结点（见后文），因此只能手动注册类集子结点的属性名和Class。JAVA1.5以上的版本我没用过，不知道可不可以解决这个问题。
数据库表关系: 这就不用多说了，就是通过外键参考。因此每类结点对应的表中，都必须有个外键，以参考它的父结点；还必须有个主键，以供它的子结点参考。各表的外键名必须相同并为一常数，否则程序生成INSERT SQL时才可以不用理会具体表的具体的外键名。
程序在解析时，遍历的是BEAN树；在持久化时也是。比起XML树，BEAN树代表真正的业务结构；比起数据库表关系树，BEAN树才能由父至子地进行先序遍历
4.其他问题
a.要让程序知道，原子属性中哪些是XML结点的属性，哪些是XML结点的原子ELEMENT。代码中这是两个抽象方法，必须让具体的结点类实现
b.回顾本文概述部分提到的“pig --content --pighead 的三级关系，无端端多了一个content结点”，因此我们要让程序知道，pighead,pigfoot等结点的子结点，究竟是pig，还是pig下的content。处理不规范XML时要注意这个问题。这也是一个抽象方法，必须让具体的结点类实现
c.与上一条类似但更变态的，是类集结点的不规范问题。假设一个pig有多个pighead，那结构可能为 pig--pighead,pighead,...，也可能为pig--pigheads--content,content.... 必须让程序知道某个具体结点用的是哪种模式
（举报）