• 【水晶报表内功心法】推拉之间


    索引
    【水晶报表内功心法】--序言
    ============================================================
    水晶报表程序控制上有两种模式,也就是传说中的PULL模式和PUSH模式。口语化点就是拉模式和推模式。
    把这个放在最开始讲,是因为模式的选择,会影响到后续的开发。
    特别是看到一些使用者,把两种模式的代码里捏在一个过程里,出了错误,都不知道怎么去调试。
    本文将讲解两种模式的基本原理,区别,以及各自的优缺点,还有部分开发报表的基本原则。
    同样,本文是没有代码的,代码将从下一篇文章开始。
    1.1 拉(PULL)模式:
    由水晶报表模板(引擎)直接连接数据库(源),从数据库(源)里拉取数据
    就是我们在水晶报表里设置好数据库信息,以及相关的表。
    当我们在程序中调用水晶报表引擎,挂载模板后,水晶报表引擎会根据模板里的数据库信息,及表信息主动连接数据库,
    返回数据给报表模板,模板根据设计样式进行呈现。
    基本流程如下图所示

    (图1-1-1)
    1.2 推(PUSH)模式:
    由应用程序从数据库(源)获取数据,然后把数据推送给水晶报表引擎。水晶报表本身不不跟数据库进行交互。
    其基本流程图如下

    (图1-1-2)
    对比两个图,黑色的箭头表示我们要自己进行编码,蓝色的箭头表示是水晶报表与数据源的自动交互过程,不需编码。
    这样我们很容易看到,使用PUSH模式将会比PULL模式多了不少代码。
    而且因为PULL模式是直连数据库,比PUSH模式的先获取数据结果,然后推送给水晶报表少了一个过程。而中间结果集本身就占用系统资源。
    所以PULL模式比PUSH执行效率高。
    那么两者的差异就出来了
    1:PULL模式代码量少
    2:PULL模式执行效率高
    3:实际开发过的朋友也有体会,使用PULL模式,模板开发的速度也比PUSH模式模板简单一些
    这几点上,似乎PULL模式已经完全把PUSH模式打败了,呵呵。
    那么为什么 PUSH模式还存在,且被大量使用呢?
    我们再返回去看上面两个示意图,
    大家注意到图1-1-1中,是由水晶报表连接的数据库,也就是说,水晶报表引擎单独占用了一个数据库连接。
    而只有在水晶报表对象释放后,数据库连接才会释放(这个时段对系统时间来说,是比较长的,特别是如果要翻页等需要长时间连接数据库的情况)。
    而在图1-1-2中,数据库是由应用程序去连接的,水晶报表本身不连接数据库。这样,系统就能使用公用的数据库连接。
    这样一来,就节约了数据库的连接消耗。
    这一点,在多用户的系统环境内,少一次数据库连接对系统性能的影响对系统的影响是比较关键的。
    当然,我们也应该注意到,PUSH因为存在一个Dataset,所以会占用系统资源。
    这两个方面大家需要综合考量。
    这是个基本的,下面我在列一下PUSH的优势。
    1:可以公用系统数据库连接,减少数据库连接损耗
    2:可自由组合多数据源(如多数据库等),这一点PULL模式也可以实现,但是不如这个方便
    3: 灵活多变
    灵活多变的说法,是因为由于我们是把数据获取后,再PUSH给水晶报表的,那么在这个中间,就有很多数据再加工的可能性。
    大家可以看一下我之前写的
    动态(万能)水晶报表:任意表,任意列,动态格线调整
    水晶报表动态表扩展 之 任意无关联表,任意列,任意数据源
    水晶报表动态表扩展 之 任意SQL及任意有关联表,任意列 及其他
    好了,总结一下:
    1:CS模式或小型系统,建议用PULL模式,大型BS系统,建议用PUSH模式。
    但这不是绝对的,可以根据实际情况混用。如果是大数据量的清单类的报表,建议用PULL。
    2:无论什么模式,返回尽可能少的数据给报表。
    3:通常情况下,无论是PULL还是PUSH模式,数据源处理部分只负责把数据传给报表,至于怎么呈现是报表里去做的
    有的人问到:做交叉表怎么传数据,做图表怎么传数据,做列表怎么传数据,实质上,做法都是一样的。
    当然,特殊情况除外。如:SQL交叉表,自定义图表等等。
    预告:PULL和PUSH模式的样板招式
    其他:本帖不回复与本文内容无关的问题。

    引用: http://topic.csdn.net/u/20090622/13/dced6fe3-3fe7-4501-9a81-be20d2f5d504.html

  • 相关阅读:
    LVM快照备份与恢复
    Docker Images for MySQL Group Replication 5.7.14
    sysbench write and read only
    Leetcode: Closest Leaf in a Binary Tree
    Amazon | OA 2019 | Optimal Utilization
    物联网架构成长之路(27)-Docker练习之Zookeeper安装
    物联网架构成长之路(26)-Docker构建项目用到的镜像2
    物联网架构成长之路(25)-Docker构建项目用到的镜像1
    物联网架构成长之路(23)-Docker练习之Elasticsearch服务搭建
    物联网架构成长之路(22)-Docker练习之Etcd服务搭建
  • 原文地址:https://www.cnblogs.com/chencidi/p/2274507.html
Copyright © 2020-2023  润新知