利用XML实现通用WEB报表打印.docVIP

开发B/S结构的应用程序最头疼的问题可能就是报表打印了，由于只能采用浏览器来作为用户界面进行交互，所以不能精确控制客户端的打印机。而很多B/S结构的应用程序常常需要完成非常复杂的报表打印任务。而靠IE自带的页面打印功能一般不能满足需要。 　　采用Crystal Report是一种大型报表系统常用和推荐的解决方案，但是如果我们只需要进行一些小规模的报表打印的话，Crystal Report则显得庞大麻烦了一点，可定制性也不太好，它的打印实际上也是利用了IE的打印功能，也不能精确控制打印效果，而且需要您对它进行注册。　　所以我们这里讨论的是另外一种办法，简单来说，如果您有下列需求中的任何一条，那么就可以尝试采用本方案。　　方案适用性 　　1. 远程数据打印。需要打印的数据并不在本地，必须进行远程读取。　　　2. 需要精确控制打印效果，包括页面格式，分页，附加条目，表格等。　　3. 出于安全性考虑，不能直接连接到数据库。　　方案原理　　其实原理很简单，通过XML强大的自定义功能，我们便能方便的自定义出我们所有需要的格式控制标签，在服务器端进行动态编码后通过WEB服务器传到客户端，然后在客户端进行格式解析，根据服务器端定义的打印格式从客户端直接控制打印机打印出我们需要的报表。　　技术选择　　由于报表打印比较复杂，为了能够精确控制打印格式，不能采用WEB浏览器页面打印的方式进行报表打印工作，只能采取自编程控制客户端的打印工作。由于.NET framework的winform可以直接嵌入到网页中，我们在这里选用了该技术，但是请注意，我这么做并不代表.NET winform是唯一的选择，其实您可以采用任何客户端代替它，例如Java Applet或者ActiveX，甚至是一个普通的应用程序都能行。　　不允许直接连接到数据库，因此只能采用XML文件进行中间数据交换格式，通过普通WEB服务器的默认80端口进行数据传输。事实上，我简直找不到其它更理想的方案了，当然，web service也许能算是一种，但是它采用的是SOAP传输数据，从原理上看，应该和我们采用的XML属于同种类技术。　　再补充说明一下我为什么要采用.NET编写的受控组件，优点在于：　　1. 它不需要进行客户端注册。相对于ActiveX的一个大优点。　　2. 比ActiveX安全性高。在.NET Common Language Runtime的控制之下运行　　3. 编写方便。我喜欢C#和Visual Studio .NET。　　4. 有很强大的打印控制功能。利用.NET framework类库。　　5. 直接支持XML技术。　　6. 和IE兼容性高。同为Microsoft公司产品。　　另外，需要注意一点就是，在.NET framework sp1和sp2中默认的安全级别是不能直接运行受控组件的，但是在.NET framework 1.1 beta中又改了回来，可以直接运行了。　　服务器端您则可以采用现有的服务器系统和数据库，不需要新添加任何新硬件设备和新的.NET服务器管理人员，他们往往是些要求拿高薪的家伙。 ：）　　服务器的工作流程为：　　1. 接受客户端的标准XML模版查询。　　2. 需要根据查询要求将数据库数据格式转换成标准的XML数据格式。　　3. 将XML数据通过80端口发送出去。　　可行性分析　　由于现在的大部分数据库都支持XML格式的数据查询和转换，如SQL Server 2000，Oracle 9i，IBM DB2等大型关系型数据库。只需要通过简单的设置就能直接进行XML数据转换工作。如果数据库不能支持直接XML数据转换，也可以籍由一些服务器端脚本程序进行脚本转换工作，比如JSP，ASP，PHP等等。客户端也不需要任何特殊的设置工作，仅需要安装一个大小为21M的.NET framework分发包，然后直接打开网页就可以进行工作。也没有操作系统限制，从windows 98到windows xp都能很好的支持。　伸缩性和安全性　　伸缩性　　由于采用的是XML标准数据格式作为中间数据交换，因此本解决方案具有非常好伸缩性，例如，客户端的.NET控件可以采用JAVA APPLET、ACTIVX或者是VB，VC等编写的客户端应用程序直接替换。服务器也可以任意选择采用IIS或APACHE等WEB服务器。数据库也可以采用任意一种数据库。包括SQL Server，Oracle或者是Access等。这点上文已经谈到过，因为文章的长一点并不会使送给我的T恤大一号，这里再强调一遍只是为了加深读者对XML的跨平台性的认识。 ：）　　安全性　　由于采用的是普通WEB服务器传送数据，因此可以直接采用SSL安全套接字等已经成熟的WEB加密技术。同时还可以对XML进行数据算法加密，在客