随着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系统等。

报表工具产品更多介绍：www.finereport.com

免费下载 体验Demo