xml|資料
除將 XML 用作一種簡單資料格式之外,資料繫結是 XML 最流行的用法之一。即使剛剛入門的程式員也能在一種原生程式設計語言中使用 XML,並且在大多數情況下完全不需要任何的 XML 專門知識。本文並不是介紹解決方案,取而代之,Brett 介紹了一些討論主題,鼓勵您思考如何使用 XML 和資料繫結。歡迎在 XML 和 Java 技術討論論壇上與別人一起分享您的想法。
XML 用於業務而非技術
隨著 XML 的日趨盛行,人們也越來越注重可用性。換句話說,程式員和管理者並不希望把 XML 看作是一項技術,擁有自己的語義和詞彙結構,而認為它更像是純粹的資料,訪問時不用擔心 XML 資料格式的細節。
完成 XML 從技術到業務格式的轉換,最簡單是方法就是資料繫結,這種說法還有待論證。資料繫結就是使用API(Application Programming Interface,API)操作 XML 文檔中的資料,這樣程式員就不必過多地瞭解 XML,不必使用角括弧,或者考慮 CDATA 部分或實體引用等等之類的事情。但即使是使用資料繫結,您也會發現在繼續操作之前有大量的選項和重要問題需要仔細考慮。
出於本文討論的目的,我將介紹兩個與資料繫結相關的基本問題:
- 通過資料繫結 API 表示資料的方法。
- 當資料被視為業務資料時的用法。
在最普通的情況下,資料繫結就是將 XML 文檔中的資料轉換成正在使用的程式設計語言中的對象。
比方說,查看下面這段 XML 代碼:
<person> <firstName>Brett</firstName> <lastName>McLaughlin</lastName> <email>brett@newInstance.com</email></person> |
我們可以將這段代碼轉換成對象,比方說在 Java™ 代碼中,這是一個 Person
類的執行個體,擁有成員變數 firstName
、lastName
和 email
。執行個體應該包含程式碼片段中的資料,並且能通過方法調用訪問該資料,例如 myPerson.getFirstName()
方法。
儘管這是最常見的資料繫結方法,但是使用 XML 文檔並把整個文檔表示成一個對象的 API 也是資料繫結的一種形式。這些 API 包括文件物件模型(Document Object Model,DOM)、JDOM 和 dom4j,所有這些 API 都用於在 Java 編碼中建立 XML 文檔的物件模型。
在這些模型中,我們使用 rootElement.getChild("firstName").getValue()
之類的調用(或者與之相似的調用,取決於 API 的細節)。雖然這確實需要一些 XML 的基礎知識(理解元素是什麼以及文檔的基本結構),但還是對程式員抽象瞭解析的細節。這就是資料繫結的本質:能夠更多地注意到資料而不是資料顯示的格式。
一旦採用了更普通的資料繫結解決方案,如 Sun's JAXB,那麼需要注意的底層 XML 文法將會更少。可以真正完全地使用 Java(或者您偏好的程式設計語言)對象、方法和變數。即使是元素的細節和文檔結構也隱藏在了資料繫結處理建立的對象之下。
但是,此處的關鍵是(經常沒有考慮到的)仍然需要將 XML 資料結構與系統中的對象匹配,或者需要在系統中建立匹配所使用的 XML 資料格式的對象。這兩種情況到 XML 的映射都不太明顯,但它仍然是處理的一部分。
我在這裡概述了兩種基本的方法,但是這兩種方法並不是像第一眼看上去那樣區別很大。使用 DOM 或者 JDOM 之類的 API 時,不管是載入 XML 還是訪問資料都需要不斷地處理文檔的結構。在第二種方法中,使用 JAXB 之類的 API 時,需要預先處理 XML,建立使用 XML 的物件模型(或者有時使用工具為您建立需要的類和對象)。然後,在運行時,將資料更多地作為業務資料來使用,可以不用考慮 XML 了。
如果 XML 不是非常易讀的格式,或者並非如希望那樣以業務目的分開,或者其格式會經常變化,則第一種方法將會是很好的選擇。該方法需要更多一點的 XML 知識以及使用 API(更多地以技術為中心而不是以業務為中心)的能力。
另一方面,如果 XML 是按照業務需求組織的,並且 XML 結構很少變化,則可以一次性的建立類和對象,然後在運行時將資料作為業務資料使用,完全不用擔心資料底層的 XML。
開發人員常常會疏於考慮:如何根據選擇的資料繫結解決方案使用 XML 文檔中的資料。但是,這可能是正確決定資料繫結方法的一個最重要的因素。
將 XML 資料轉換成對象執行個體的資料繫結方法只適用於那些要多次使用的資料。擷取 XML 文檔中的資料並將其轉換為多個對象中的成員變數資料涉及大量的處理工作。要從這個方法中獲利,需要多次使用到該資料。
仔細查看一條資料的訪問次數,同時也考慮一下使用了多少資料。比如說,假設 XML 中為每個人存放區了 20 條資料,但應用程式中只訪問了其中的一條,使用大量的資源轉換資料卻只是為了訪問其中的一條。不論怎樣計算這都不可能獲利。
隱藏儲存介質是使用基於對象的方法的另一個重要原因。因此應用程式中可能有一個組件對 Person
對象執行一些特殊的處理。可以從資料庫或者 XML 文檔或者屬性檔案中讀取 people 資料,然後把這些資料轉換成 Person
對象,再把這些對象傳遞給處理組件。
即使只是暫時使用資料,這也是用對象表示資料的一種很合理的情形。在本例中,如果將資料表示為對象格式,並且應用程式的其它部分已瞭解如何使用該格式,則可以獲益。同時還避免了組件的資料轉化和資料載入,而您只希望使用某種類型的對象來實現相應操作,這很好地實現了應用程式中的關係隔離,而它正是應該遵循的一條重要的設計原則(應用程式中的每個組件只實現一個功能,並實現好該功能)。
如果沒有要重用的資料,而且不以對象的形式將資料傳遞給應用程式中的另一個組件,則可以考慮使用 DOM 或者 JDOM 之類的 API。這比將 XML 轉換成非文檔格式所使用的資源少,從而可以全面受益。此方法比以高昂的代價將資料轉化為特定於業務的對象、以後卻只使用該資料一二次要好得多。
儘管本文的主題是資料繫結,但有一點值得提到的是在這些情況下甚至可以考慮使用 SAX(Simple API for XML)這樣的 API,它完全不提供物件模型(以文檔或對象格式)。使用它處理 XML 只使用很少的記憶體和時間,如果確實只需要使用一條資料一到兩次,則此方法可讓您獲益巨大。使用像 SAX 這樣的 API 需要更多的瞭解 XML 的知識,但瞭解這些知識是非常值得的。
這篇關於XML 和 Java 技術 的系列文章不是提供問題的解決方案,而是希望能讓讀者自己思考如何使用一種特殊的技術和 API —— 本例討論了 XML 和資料繫結。您可能會同意其中的某些觀點,而不同意另外一些觀點。但是應該明確的是,一定要更深入地思考如何在自己的應用程式中使用 XML。
本文旨在為讀者提供一個起點。歡迎訪問 XML 和 Java 技術論壇,在那裡將以更加互動的形式繼續這些討論。如何使用資料繫結,您最喜歡使用哪一種 API,是否想出了資料繫結技術在應用程式中的一些創造性用法?請與我分享這些資訊……我期待在網上與您進行交流