f→Dcom的顺序从大到小存放变量和数据对象。具体约定如下：

Bfun 系统级全局变量。如：用户的登录信息和操作记录。

Aapp 功能级全局变量。如：步骤状态参数、功能常数。

Cbuf 如果一个功能在操作上存在多个步骤，在其中不确定的连续几个步骤中会用到的公共数据就保存在这个
框架中，如一个缓冲表。

Dcom 针对Cbuf，此框架只保存在多个步骤中的一步里需要用到的数据。如：函数计算结果。

Cbuf及Dcom框架中保存的数据主要从服务器上取得。

3．程序流程说明

在一个具体的功能中，Aapp对整个程序流程进行控制。Aapp通过对象关系取得Bfun中的变量值或调用Bfun中的函数。而Cbuf及Dcom中会包含一个完整的服务器端处理流程，AAPP在适当的时候将业务流程控制权交给Cbuf或Dcom，Cbuf或Dcom在流程执行完成之后必须将流程控制权还给Aapp。由于借助了DOM中对象的方法与触发事件,Aapp中可以实现部分数据更新,就象一个C/S中的客户端程序。

如上图，Cbuf与Dcom负担了与WEB SERVER及DATABASE的数据交换工作，使Aapp在第一次被装入后就只需要在客户端浏览器中运行。这样，Aapp中的主要界面就不需要进行刷新，避免了页面刷新时造成的延迟和闪烁问题。而Cbuf与Dcom中可以只根据约定格式返回数据和一个事件触发脚本，数据传输量可以根据需要降

到最小，又因为Cbuf与Dcom没有可视界，因此在浏览器中的加载速度也是最快的。另外，Bfun中保存了大部分的函数和变量，即使Aapp的页面需要重载，也只需要重载该页面专用的一部分内容。

4．数据存储格式约定

将数据写入Aapp界面中的方式有两种：

一种是在Cbuf与Dcom定制脚本将数据写到Aapp中；

另一种则是由Aapp中的脚本读取Cbuf与Dcom中的数据再写到自已的界面上。

两种方法最终都要保证Aapp取得程序流程控制权。

当从服务器上取到的数据比较少时（比如出错提出示信息），前一种方法是可行的。但当从服务器取回的是一个数据集合（比如多行的记录集）时，前一种方法会造成控制脚本太长的问题，而且灵活性也不如后一种方法。而且按照各框架的分工，数据的控制功能应该由Aapp去完成。因此后一种方法是数据控制的主要方法，但采用后一种方法必须在Cbuf与Dcom中定义一个数据格式。

在数据量少的时候，可以用变量保存数据，变量名可以在提交URL时定义，也可以使用默认变量名。两种定义方式性能差别不大，具体采用那一种可以根据个人喜好而定。

在数据量比较大时，最常见的情况是在服务器上取回了一个若干行的记录集。这时可以采用表格保存数据。具体格式如下：

假设在提交ASP文件的URL时定义的表格对象名为rsTest，则会返回两个表格对象rsTest和rsTestStru。

RsTestStru用来存放记录集的列属性数据。这个表由固定的五列组成：

1．ID 列顺序号

2．NAME 名称

3．TYPE 数据类型

4．LENGTH 长度

5．PREC 小数位

RsTest用来存放记录集的各行数据。

在DOM中，表格对象的行和列都有属于相应的对象集合。通过指定行和列的序号能够很准确的定位到任何一个数据元素，再结合innerText属性便可以取出想要的数据。但DOM并没有给出对表格元素进行排序及查找的方法，因此我们必须自己编写这方面的函数脚本。

对于实际的WEB-MIS，还要考虑ASP及数据库方面的程序优化问题；一些额外的功能，如打印控制等，仍需要借助ActiveX或Java applet来实现，这里不作讨论。

四、应用实例

本方案在“深圳市自来水公司管理信息系统（SW-MIS）”的“抄表收费分系统”中获得了应用，“抄表数据录入”功能在采用本方案进行优化后，在50个并发用户的测试中达到了不少于10条/（用户*分钟）的录入速度。而且WEB SERVER与SQL SERVER的CPU占用率能够始终保持在10%左右。

上一页  [1] [2]