C#發現之旅第十講 文件物件模型

C#發現之旅第十講 文件物件模型

袁永福 2008-5-15

系列課程說明

    為了讓大家更深入的瞭解和使用C#，我們將開始這一系列的主題為“C#發現之旅”的技術講座。考慮到各位大多是進行WEB資料庫開發的，而所謂發現就是發現我們所不熟悉的領域，因此本系列講座內容將是C#在WEB資料庫開發以外的應用。目前規劃的主要內容是圖形開發和XML開發，並計劃編排了多個課程。在未來的C#發現之旅中，我們按照由淺入深，循序漸進的步驟，一起探索和發現C#的其他未知的領域，更深入的理解和掌握使用C#進行軟體開發，拓寬我們的視野，增強我們的軟體開發綜合能力。

課程說明

    本課程專門講述文件物件模型的概念，理論性比較強，需要仔細思考，而且沒有示範程式,本課程是C#發現之旅系列課程的終結篇,不過不排除我今後推出C#發現之旅續集的可能性。
本系列課程發行的文章有
C#發現之旅第一講 C#－XML開發
C#發現之旅第二講 C#－XSLT開發
C#發現之旅第三講 使用C#開發基於XSLT的代碼產生器
C#發現之旅第四講 Windows圖形開發入門
C#發現之旅第五講 圖形開發基礎篇
C#發現之旅第六講 C#圖形開發中級篇
C#發現之旅第七講 C#圖形開發進階篇
C#發現之旅第八講 ASP.NET圖形開發帶超連結的餅圖
C#發現之旅第九講 ASP.NET驗證碼技術
C#發現之旅第十講 文件物件模型

文件物件模型定義

    文件物件模型英文名為 Document Object Model , 簡稱DOM，它是一種比較重要的軟體設計模式，不是編程技巧。可以這麼說，平生不認DOM，便稱英雄也枉然，大家應當多多瞭解它的能力。

    文件物件模型是物件導向編程技術的集中體現，若沒有完整的物件導向編程思想，是不可能理解和開發文件物件模型，若開發人員能開發出文件物件模型，那就說明他/她比較完整的理解和掌握了物件導向編程思想。

    W3C國際組織對文件物件模型是這樣定義的（摘自 http://www.w3.org/DOM/ ）

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.

    以我個人的英文水平翻譯如下

文件物件模型是一種平台或語言中立的介面，程式或指令碼能利用它來訪問和更新結構化的文檔。這些文檔可以被進一步的處理，處理結果可以組成一個有效頁面。這是W3C對web上的文件物件模型原理的一般看法。

文檔

    我們來逐步理解這個定義。首先什麼是文檔。文檔就是以一種結構組織在一起的資料包。比如MS Word 文檔就是一種文檔，它包含了很多字元，圖片，段落資料，並使用特定的組織圖儲存在一個二進位檔案中。 比如HTML文檔，它也包含了文字，圖片，連結，表單資料，並可以按照公開的HTML文法組成一種階層儲存在一個字串或文字檔中。

結構化文檔

    其次，什麼是結構化的文檔，很多文檔它的內容組織呈現一種層次化的結構。即它的內容抽象化可以組成一種樹狀結構，比如HTML文檔，XML文檔。

    對於普通的文字文件，從開發人員看來，它就是一個字串，其中各個字元或子字串之間是沒有相互關係的。此時普通文字文件就不是結構化的文檔，若將某種支援階層的文法分析強加到這個文字文件時，則該文字文件就成了一個層次化的文檔。

    HTML文檔若沒有進行HTML文法解釋，則它就是一個平淡無奇的純文字文檔，就是一個普通的字串，若將HTML文法強加到這個字串，則這個純文字文檔立即成為具有相當複雜度的結構化文檔。同樣的道理，XML檔案，SQL語句等純文字文檔，在它沒有解釋前是一個普通的字串，解釋之後就成為大有用途的XMLDOM，SQLDOM。

編程介面

    DOM是一種介面或平台，對於軟體開發人員來說，這種所謂的介面或平台就是編程介面（API），API有很多種，有直接調用函數的介面方式，比如傳統Win32API函數，還有一種是暴露可程式化對象，編程對象有公開的屬性方法或事件，比如COM介面或.NET類庫介面。還有基於WEB的WebService的編程介面。一般而言，對於DOM，編程介面就表現為可程式化對象的編程介面，就是DOM向外發布若干個可程式化對象，別的應用程式或者指令碼語言可以調用這些可程式化對象的公開成員。

    DOM的一個重要特性就是應用程式或者指令碼程式能利用它來訪問和更新結構化文檔。這個意思是說，DOM向外提供若干個可程式化對象，這些對象內部使用種種手段，保證它和結構化文檔中的某個部分保持對應關係，特別是對象的屬性和文檔片斷的屬性保持映射關係。而外部程式獲得可程式化對象的屬性，經過DOM內部的映射關係，實際上就等價於獲得某個文檔片斷的某個屬性，外部程式修改可程式化對象的屬性，經過內部的映射關係，最終導致某個文檔片斷的屬性的修改。因此DOM是應用軟體和結構化文檔之間的代理，應用軟體使用DOM透視出文檔的內容，也通過DOM“隔山打牛”的方式修改文檔內容。

有效頁面

    最後結構化文檔處理後，可以形成一種有效頁面，也就是結構化文檔可以展示在使用者介面上。一般的應用程式藉助DOM，可以在使用者介面上繪製結構化文檔的內容。比如WEB瀏覽器，藉助HTML DOM，在使用者介面上繪製出HTML文檔的樣式。一些結構化文檔沒有使用者介面，比如XML文檔，但它具有可程式化使用者介面，其他的應用系統可以使用這個可程式化使用者介面來獲知XML文檔中到底有什麼內容。

    文件物件模型可以是語言中立的，也就是說跨語言跨平台，比如HTML和XML的文件物件模型，在W3C國際標準組織的努力下，已經是最典型的跨語言跨平台的文件物件模型，我們可以使用任何平台和語言來使用相同的方式和介面來訪問XML和HTML，比如無論是Linux下的JAVA，Windows下的.NET，VB或各種瀏覽器中的JavaScript，甚至是MS Office 中的VBA，他們訪問XML DOM的過程必然是類似的，很容易使用相同的處理流程來實現相同的功能。這樣做的好處就是大大的方便程式的移植和各種系統之間交流資料。

    可以這麼認為，若文檔具有生命，則它在儲存在檔案時，它就處於休眠狀態，就差不多是死的，但一旦被DOM附體，它被喚醒了，就是活的，可以任由應用軟體調遣，可以發揮任何應有的功能。

    以上是我個人對文件物件模型的理論認識，接下來說說如何在軟體開發中理解文件物件模型。

理解文件物件模型

    文件物件模型是一種規範，在微軟.NET架構類庫中實現了兩種DOM，CodeDom和XMLDom。名稱空間 System.CodeDom下定義了CodeDom，名稱空間System.Xml下定義了XML Dom，這裡使用大家比較熟悉的XML Dom 來講解一番。

XmlDom結構研究

    這個圖是XML文檔和XML對象之間的映射關係圖。

    

    大家經過以前的課程的學習，已經掌握了基本的XML文法，因此這裡不再詳細說明這個XML文檔的文法結構了。在這個映射關係圖中，我們使用XmlDocument對象來影射整個XML文檔；使用XmlDeclaration來影射”<?  ?>”定義的XML聲明，；類似的我們使用XmlElement對象來影射一個XML元素；使用XmlText來影射XML文檔中的純文字資料；使用XmlAttribute來影射XML屬性片斷；使用XmlComment來影射XML注釋。

    經過上述影射，開發人員可以通過編程調用各個XML對象來修改XML文檔中對應的部分。比如我們調用XmlText類型的Value屬性，就能很方便的獲得和修改XML文檔中的純文字資料片斷。

XmlDocument類型定義了很多以Create開頭的函數來建立一個新的Xml對象，比如我們可以使用CreateElement函數建立一個XmlElement對象，然後添加到某個已有的XmlElement的ChildNodes列表中，這樣的操作就相當於向XML文檔新增元素的操作；我們也可以刪除某個已有的XmlElement的ChildNodes中的對象，這相當於從XML文檔中刪除了一個片斷。

    通過編程對象和XML文檔的映射關係，我們就將操作XML文檔的操作轉化為對一個個編程對象的操作。我們就能比較方便的使用編程來處理具有複雜文法結構的XML文檔。

    考察XmlDocuement，XmlElement，XmlText等等XML文檔組成元素，可以發現它們都是從XmlNode這種類型派生的，XmlNode中定義了Xml對象通用的編程介面，而其他Xml類型都從XmlNode派生的，並根據各自對應的XML片斷類型進行了擴充。這樣我們可以很方便的使用XmlNode作為強型別來遍曆XML文檔。

    事實上，名稱空間System.Xml下面存在比較複雜的對象繼承關係，比如存在這樣的派生關係鏈表XmlNode->XmlLinkedNode->XmlCharacterData->XmlText。為什麼要設計如此的長的派生鏈表，每層應當實現什麼樣的功能，預留什麼樣的介面，每層又如何擴充上層類型的成員。所有的這些都是考驗開發人員的物件導向編程技術的基本功和軟體設計思想，因此若一個開發人員能理解和設計比較複雜而合理的DOM，則此人必是軟體設計高手。

    一般情況下我們進行編程，同一個列表中儲存的對象，它們的類型是一樣的，可以放心大膽的使用強制類型轉換來獲得列表中的任意元素。但在XML文檔物件類型中，同一個列表中的物件類型可能不一致，無條件的強制類型轉換是不可靠的，容易出錯，因此強制轉換前需要進行類型判斷。而且這種現象普遍存在於其他的文件物件模型中，比如HMTLDOM中，一個HTML節點的子節點也存在類似情況，因此針對文件物件模型編程時需要注意這點。但由於所有的Xml物件類型都是從XmlNode上派生的，因此我們可以可靠的使用XmlNode類型來遍曆XML文檔結構。

     XmlDom中包含了一個以XmlReader為基礎的XML文檔解析器，我們調用XmlDocument的Load方法，系統就能從一個檔案中載入文本資料並解析，自動構造出一個以XmlDocument為根節點的Xml對象樹狀結構。XmlDom中還包含了一個以XmlWriter為基礎的XML文檔書寫器，當我們修改了XML對象樹狀結構後，調用XmlDocument的Save方法就能把修改過的Xml文檔儲存到一個檔案中。這樣就完成了對Xml文檔的修改。

    如果我們不用XMLDOM，我們如何編程來訪問XML文檔？很顯然，這時的XML文檔就是一個字串，我們需要對這個包含XML內容的字串進行很複雜的字串操作，軟體開發過程複雜而低效率，XML技術由於難以開發和使用而必然得不到推廣。

DOM概念內涵

    經過XMLDOM的研究，我們可以歸納出DOM的一些基本的編程特性：

1. 所有的文檔物件類型都是從一個基礎類型派生的，文檔物件類型都在基礎類型上實現了各種特性。
2. 每個文檔對象都映射了文檔中某個片斷，修改文檔對象就等價於修改文檔片斷本身。
3. 文檔對象可以有子節點，由此構成一個多層次對象樹狀結構。
4. 存在一個頂級對象，用來表示整個文檔。可以宏觀控制整個文檔，也是應用程式訪問文檔對象樹狀結構的唯一入口。
5. 文件物件模型是可程式化的，應用程式通過訪問文件物件模型來訪問結構化文檔。
6. 大部分類型的DOM可以將整個文檔結構儲存到一個檔案中，也可以從一個檔案中再現整個文檔結構。這算對象序列化。但也可能有例外。

    我們可以發現，其他的DOM都基本上實現了上述編程特性，比如名稱空間System.CodeDom支援下的CodeDom，HTML DOM。

DOM概念外延

    XMLDOM是嚴謹的DOM的編程特性，但我們在實際開發應用中，可以根據各種需要進行簡化，開發各種不夠嚴謹的DOM。 比如在微軟.NET標準庫中，存在著許多不嚴謹的DOM結構。比如名稱空間System.IO下的FileSystemInfo ，FileInfo，DirectoryInfo組成了檔案系統DOM；名稱空間System.Reflection下的類型組成了以Assembly為根節點的程式集DOM；名稱空間System.Windows.Forms下的類型組成了以Form為文檔對象，以Control為基礎類型的WinFormDOM；名稱空間System.Web.UI及其子名稱空間下的類型組成了以Page為文檔對象，以Control為基礎類型的ASP.NET頁面DOM。可以說，一般的對象樹狀結構都可以看作不嚴謹的DOM結構。

    我們學習了XMLDOM後，就可以模仿著設計自己的DOM，在開源網站 http://sourceforge.net 上，使用關鍵字 DOM 進行尋找，會找出很多開源項目，這些開源項目大多都和各種各樣的DOM有關係。

    文檔就是資料，DOM處理文檔，實際上就是處理資料，因此更進一步，我們開發開發各種應用系統中，都可以借鑒一下DOM的設計思想，比如開發WinForm或ASP.NET中，這些使用者介面控制項時也可以看作DOM。做電子病曆時，可以設計出電子病曆文件物件模型，做客戶關係管理系統時，可以設計出客戶文件物件模型。總之做XX系統時，可以考慮設計出XX文件物件模型。

小結

    文件物件模型是一種比較複雜的軟體設計技術，但它功能強大，層次分明，邏輯清晰，好的文件物件模型合情合理，符合人們想當然的思想，是商務邏輯資料的高度抽象。大家應當好好學習，多多研究學習學習，這對提高軟體設計能力，樹立自己的物件導向的編程思想都大有好處。