摘要
开发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. 需要根据查询要求将数据库数据格式