本文配套源码
您现在应该具备的（回顾）
与前一篇文章一样，本文也对您系统的设置情况和您的技能做一些假设。首先，需要按照本系列的第1部分中的描述下载并安装Castor的最新版本，设置类路径和相关的Java库。然后，按照第2部分中的描述，熟悉Castor的基本编组和解组设施。
所以，您应该能够使用Castor提取出XML文档中的数据，并使用自己的Java类处理数据。用数据绑定术语来说，这称为解组（unmarshalling）。反向的过程称为编组（marshalling）：您应该能够把Java类的成员变量中存储的数据转换为XML文档。如果您还不熟悉Castor的解组器和编组器，那么应该阅读 第 2 部分（参见 参考资料 中的链接）。
非理想环境下的数据绑定
初看上去，您似乎已经掌握了有效地使用Castor所需了解的所有过程：设置、编组和解组。但是，您到目前为止学到的所有东西只适用于所谓的理想环境。在这样的环境中，每个人编写的XML都是完美的，其中的元素名是有意义的，比如 “title” 和 “authorAddress”，而不是 “t” 或 “aa”。Java 类是按照有组织的方式创建的，采用单数作为类名（比如 “Book”），采用单数名词作为成员变量名（比如 “isbn” 和 “price”）。另外，数据类型也是正确的：没有开发人员把 price 的数据类型设置为 int 而不是 float，或者使用 char 数组存储字符串数据（这是 C 语言的做法）。
但是，大多数程序员所处的环境并不完美（我真想找到一个能够把我送到完美世界的魔法衣厨）。在大多数程序员所处的环境中有许多不理想的情况：XML 文档常常有糟糕的元素名和属性名，还要应付名称空间问题。元素数据存储在属性中，一些数据甚至由管道符或分号分隔。
Java 类是继承的，对它们进行重新组织在时间和工作量方面的成本可能会超过带来的好处。这些类常常无法简洁地映射到 XML 模式（认为 XML 和数据人员会与 Java 程序员相互妥协的想法也是非常不可思议的），而且在某些情况下，即使实现了简洁映射，也肯定不会跨所有类和数据。XML 元素名可能不合适，许多 Java 变量名也可能不合适。甚至可能遇到使用 Hungarian 表示法的名称，按照这种表示法，所有成员变量都以 “m” 开头，比如 mTitle。这很不好看。
在这些情况下，您目前学到的数据绑定方法就无能为力了。XML 文档中可能会出现 Hungarian 风格的元素名，Java 类中也可能出现没有意义的结构。这种情况是无法接受的。如果不能按照您希望的方式获取和操作 XML 文档的数据，那么 Castor（或任何数据绑定框架）又有什么意义呢？
灵活数据绑定的目标
首先要注意，在 Castor 或任何其他数据绑定框架中，使用映射文件都要花一些时间。必须先学习一些新语法。尽管映射文件使用 XML 格式（大多数框架都是这样的），但是您需要学习一些新元素和属性。还必须做一些测试，确保 XML 和 Java 代码之间的相互转换产生您希望的结果。最后，如果亲自指定映射，而不是让框架处理映射，就可能在数据绑定中遇到更多的错误。例如，如果希望让框架把 XML 中的 fiddler 元素映射到 Java 代码中的 violin 属性，但是错误地声明这个属性是在 player 类中（应该是在 Player 类中），那么就会遇到错误。因此，在亲自指定映射时，必须非常注意拼写、大小写、下划线、单引号和双引号。
在学习使用映射文件之前，应该确定确实需要这么做。如果掌握了映射文件，但是却不使用它，那就是浪费时间。但是，映射确实有一些优点。
Java 代码不再受 XML 命名方式的限制
前面曾经提到，在把 XML 转换为 Java 代码时，大小写可能会导致错误。在 XML 中，最常用的做法是名称全部小写并加连字符，比如 first-name。有时候，甚至会看到 first_name。这样的名称会转换为很难看的 Java 属性名；没人愿意在代码中调用 getFirst-name()。实际上，在大多数由程序员（而不是 XML 开发人员或数据管理员）编写的文档中，往往使用驼峰式（camel-case）命名法，比如 firstName。通过使用映射文件，很容易把 XML 风格的名称（比如 first-name）映射为 Java 风格的名称（比如 firstName）。最棒的一点是，不需要强迫 XML 人员像 Java 程序员那样思考，这往往比学习新的映射语法困难得多。