实用数据绑定: 往返和 XML 到 Java 的转换 2

 基本步骤

准备好了 XML 和 XML Schema，生成 JAXB 类就很简单了。确认已设置好命令行和环境，然后输入以下命令：

双击代码全选

1	xjc　-p　com.ibm.dw　guitars.xsd　-d　src

　　一定要在和 guitars.xsd文件相同的目录中执行上述命令，并且在工作目录中建立一个 src目录。如果没有按这些步骤操作，就会出现某种 java.io.IOException 错误。否则应该能看到一长串的输出结果，如清单 3 所示。

　　清单 3. JAXB 类生成的输出结果

双击代码全选

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

C:\developerworks>xjc　-p　com.ibm.dw　guitars.xsd　-d　src　 parsing　a　schema...　 compiling　a　schema...　 com\ibm\dw\impl\runtime\MSVValidator.java　 com\ibm\dw\impl\runtime\SAXUnmarshallerHandlerImpl.java　 com\ibm\dw\impl\runtime\ErrorHandlerAdaptor.java　 com\ibm\dw\impl\runtime\AbstractUnmarshallingEventHandlerImpl.java　 com\ibm\dw\impl\runtime\UnmarshallableObject.java　 com\ibm\dw\impl\runtime\SAXMarshaller.java　 com\ibm\dw\impl\runtime\XMLSerializer.java　 com\ibm\dw\impl\runtime\ContentHandlerAdaptor.java　 com\ibm\dw\impl\runtime\UnmarshallingEventHandlerAdaptor.java　 com\ibm\dw\impl\runtime\SAXUnmarshallerHandler.java　 com\ibm\dw\impl\runtime\ValidatorImpl.java　 com\ibm\dw\impl\runtime\ValidatableObject.java　 com\ibm\dw\impl\runtime\UnmarshallerImpl.java　 com\ibm\dw\impl\runtime\NamespaceContext2.java　 com\ibm\dw\impl\runtime\Discarder.java　 com\ibm\dw\impl\runtime\NamespaceContextImpl.java　 com\ibm\dw\impl\runtime\ValidatingUnmarshaller.java　 com\ibm\dw\impl\runtime\UnmarshallingContext.java　 com\ibm\dw\impl\runtime\GrammarInfoImpl.java　 com\ibm\dw\impl\runtime\ValidationContext.java

　　实在是有点太多了--注意，即使对于一个相当简单的 XML Schema，JAXB 也创建了 大量的类。

　　对往返的影响

现在我已经介绍了基本的步骤，下面将实际分析一下其中到底发生了什么。不必浪费时间回顾 JAXB 的基础（其他文章已经做了很好的介绍），对于每个元素都有两个源文件，一个文件和元素同名（比如，Guitar.java），另一个则在元素名后面加上 “Type”（如 GuitarType.java）。这两个文件都是接口，类的实现在子目录 impl 下。这样就生成了很多类--我认为有点太过分了。

　　但真正有意思的是这些类本身。要知道数据绑定实现的主要问题之一是往返--即从 XML 到 Java 代码再返回到 XML 的过程中数据不会发生不可预料的变化的能力。换句话说，进去的是什么出来的就是什么。在目前，您还没有准备好通过解组-编组循环测试输出的结果（尽管以后要这样做），首先来分析源代码中可能存在的潜在问题。

　　第一个问题出现在任何数据绑定软件包通常都会出问题的地方：类型化。即使有 XML Schema 的帮助，XML 也不一定能和 Java 类型很好的匹配。这通常意味着要损失一些数据类型信息，有可能掺入非法的数据。有时候问题出在 XML Schema 中，有时候则是因为 XML 到 Java 映射的局限性，必须仔细观察。源代码中发现的一个此类问题是 top 元素的表示。注意清单 4 中粗体显示的那一行，这是 TopType 类的源代码。

　　清单 4. TopType.java 的源代码

双击代码全选

1 2 3 4 5 6 7 8

package　com.ibm.dw;　 public　interface　TopType　{　 　　java.lang.String　getValue();　 　　void　setValue(java.lang.String　value);　 　　　　　　java.lang.String　getBearclaw();　 　　void　setBearclaw(java.lang.String　value);　 }

　　回头再看一看源文档及其 XML Schema，很明显 bearclaw 属性的值应该是“true”或“false”。不幸的是，JAXB 没有发现这一点并使用布尔数据类型， TopType 类的这个属性可以接受任何字符串值。结果可能造成错误的数据。最终可能出现“True”、“true”、“tRUe”或者任何其他变化形式，而令使用 XML 的应用程序举止失措。换句话说，您碰到了必须解决的一个问题域。

　　这类问题可能有以下不同的解决办法：

　　手工编辑 TopType 类的源代码，只接受布尔值。

　　向 TopType 方法中手工添加异常处理代码，保证只能提供可以转化成布尔值的字符串。

　　在 XML Schema 中创建表达布尔数据类型的新类型。

　　前两种选择非常明显。第三种选择也很简单，尽管 W3C 那帮人实际上应该把这一条放在规范中说明。清单 5 给出了一个简单的布尔类型定义：