實現Castor資料繫結，第3部分:模式之間的映射

本文配套源碼

您現在應該具備的（回顧）

與前一篇文章一樣，本文也對您系統的設定情況和您的技能做一些假設。首先，需要按照本系列的第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 程式員那樣思考，這往往比學習新的映射文法困難得多。