隨著B/S系統的普及和XML技術的深入應用，越來越多的數據以XML的形式被存儲和傳遞。這些數據大多源自資料庫，經過一定的處理後，數據更精簡，也更貼近應用。如果報表開發工具能利用好這些XML數據，就可以大大減少資料庫查詢和報表數據運算的操作時間。

傳統的報表開發工具一般只能處理關係型資料庫，對於其他數據源的數據則無能為力。隨著時代的發展，一些報表開發工具加上了處理XML文檔等數據源的能力，但還需要編程、並配置插件，如此以來，報表程序結構複雜，介面眾多，用戶還需要根據各種規範動手編寫程序，若XML文檔格式有很多種，就需要編寫很多種的插件，報表開發也是一個相當有分量的工作了。

如果實現了一種能處理XML文檔，從中獲得報表數據的通用方法，在製作報表模板的時候就可以從XML文檔獲得數據，實現大部分的XML文檔無需編程，就可實現數據的讀取和存入的效果，這樣報表的開發量就大大降低。

那麼如何通用化地處理具有複雜樹狀結構的XML文檔呢？

處理XML文檔有兩種模式：DOM方式和流模式。DOM方式處理方便，但速度慢耗內存，流模式處理速度快，省內存但使用不方便。對於.NET平台，使用System.Xml.XmlDocument對象來使用DOM方式處理XML文檔，而使用XmlReader 來使用流模式處理XML文檔。

W3C國際標準組織設計XML文檔的目標是方便的存儲和交換小型數據包，而不考慮數據的冗餘。因此若實際系統中出現巨大的XML文檔，則大多數情況下可以認為是不恰當的使用XML技術。因此我認為報表開發工具不應當處理巨大的XML文檔，在此前提下，為了實現方便，採用DOM方式來處理XML文檔。

在.NET中使用XmlDocument載入一個XML文檔後，會形成一個以XmlDocument為根節點的XML對象樹狀結構，面對這個XML樹結構，獲取其中數據的方法就是使用XPath技術。XPath技術就是在XML樹狀結構中，以某個節點作為起始節點，使用特定的描述表示的路徑移動到其他的節點，一般的是向其下層節點移動，比如移動到某個子節點或孫節點，移動到某個屬性等等。

傳統的報表數據源模型是兩層的，即使擴展到可以處理XML文檔也只能處理一次，既從根節點出發，使用某個XPath 獲得欄位的值。如此只能處理一次，處理完畢後XML就被扔掉了。但很多時候需要對XML文檔進行進一步處理。此時傳統的兩層報表數據源模型是不夠的。

為了能對XML文檔進行精耕細作，需要從傳統的兩層數據源結構突破到多層的報表數據源模型。在多層數據源節點中，每一個節點都映射到XML文檔中的某個節點，而它的子節點則使用XPath路徑映射到XML中的其他節點。如此遞歸循環後則多層的數據源可以映射到XML文檔中的任意節點。多層數據源模型實際上就是一個數據源樹，因此處理XML文檔也就是將兩顆樹在某些節點上釘在一起，而XPath就是釘子。因此需要注意各級數據源節點的XPath配置的連續性，若一個數據源節點的XPath設置不對，就像它釘錯了XML節點或者乾脆釘在空處。則它本身和所有的子孫節點都都會綁定落空的。

實際應用中，由於XML文檔不是專門為報表而產生的，因此報表開發工具可能要離開XML文檔來獲取更多的報表數據，此時可能需要從XML文檔跳到其他XML文檔，或者返回資料庫繼續執行資料庫查詢。這就非常考驗報表數據源模型的靈活性了。

如果一個信息系統是純XML應用的話，則報表開發工具就可以在眾多的XML文檔中跳躍著採集數據而不需要查詢資料庫，就像少林寺的武僧在梅花樁上打架而不用碰地，因此也就不用管下面是JAVA土壤的還是.NET土壤。此時所有的資料庫操作，業務邏輯等等都運行在後台，而報表開發工具無需關心，只要系統底層安全可靠，則報表模塊也就安全可靠，系統底層無論如何修改，只要XML文檔格式不變則報表模塊就不需要修改。對於非常複雜的報表數據源，超出了報表開發工具的定製能力，則可以編程提供一個XML文檔供報表程序使用。以前系統是直接通過API向報表程序提供複雜報表數據，而現在通過XML文檔以「隔山打牛」的方式向報表程序提供複雜報表數據。此時系統結構更安全，邊界更清楚，體現了XML WebService的指導思想。這種獲取數據的思想可以不局限於報表數據的獲取，還可以應用到其他領域。

忽略報表開發工具與xml數據源對接的難易程度，xml作為一種目前比較常用的數據存儲類型也應該得到報表工具的支持。目前國內支持xml數據源的報表開發工具不多，比較有代表性的是FineReport。FineReport支持多種不同的數據來源，包括資料庫，Excel文件，文本文件，XML，程序數據集，內置資料庫，SAP系統等。

喜歡這篇文章嗎？歡迎分享按讚，給予我們支持和鼓勵！