【摘要】在INTRANET上设计基于WEB的MIS时，大批量数据录入变成了操作上的瓶颈，并给WEB SERVER与DATABASE造极大的负担。

为解决这个问题，我们设计了多框架结构，将应用的功能进行细分，然后交给各框架分别完成，这种分工协作方式可以使操作界面上的数据实现受控的部分刷新，有效地减小了网络的数据传输量，缩短了各部分的处理时间，同时了也大大减轻了WEB SERVER与DATABASE的系统负担。

多框架解决方案采用ASP（ActiveX Server Pages）及ADO(ActiveX Data Objects)完成与数据库的交互工作。采用DOM技术解决和框架之间的协作问题。

关键词：多框架

*注：本文中讨论的方案中WEB服务器为IIS4.0、客户端浏览器为IE4.0以上版本。

一、问题的提出

最初，我们采用ASP及ADO技术在INTRANET上设计基于WEB的MIS（下文简称MIS）时，沿用了以往设计WEB站点时的设计习惯。但随着设计的深入，我们发现，现有的系统结构无法承担大批量的数据录入工作，因此，必须重新构造系统的总体设计结构。

MIS与普通的WEB站点之间最大的区别在于处理信息的方式。普通WEB站点的主要功能是发布信息，采集信息只是它极小的一部分功能，而且这些信息采集功能也都是比较简单的。但对于MIS系统来说，信息的采集及维护工作占有比较高的比例，在这些信息采集功能中还存在一些较为复杂及大批量的数据录入功能，这些功能成为了系统中的设计难点。

二、问题的分析

当一个系统涉及到复杂及大批量的数据录入功能时，同时也就涉及到了响应速度及界面的问题。在以往的C/S方式中，客户端的录入速度由录入员来控制，一般情况下，当录入员熟悉了操作方式之后，录入速度是不受系统限制的。但在WEB方式下，页面采用完全刷新方式，每次的交互操作至少要造成一个页面的刷新。这种刷新的工作不仅更新了数据，也将界面上的一些固定内容重新加载了一遍。对于普通用户来说，这种短时间的刷新并不会造成影响；但对于长时间进行操作的录入员来说，录入一条数据就要等待一段时间（这一段时间可能是2-3秒，也可能是十几秒甚至几分钟），是绝对不能接受的。即使，网络有足够的带宽，页面的重载也会造成一种闪动的效果，这种一闪一闪的刷新造成录入员必须重新识别页面上的各种元素，不仅也会拖慢了他们的录入速度，还造成眼睛的快速疲劳。

三、解决方案

如果能够“不”刷新页面而“快速更新”页面中的数据，问题应该能够解决了。而且页面由于没有刷新，一些必须由服务器保存的状态信息也能够在客户端保存下来了，从而减轻服务器的负担。那么如何达到这个目标呢？下面将详细讨论。

1．设计思路

首先，我们确立采用多框架建立页面。框架(Frames)其实不是什么新东西，许多站点上都用它来完成显示固定标题及菜单的功能。采用框架能够避免一些页面的重复访问。但是如果结合使用DOM（Document objects model)，框架可以完成许多细致的工作。

按照DOM的定义，框架可以被当作一个对象。假设我们建立了一个框架，并给它取名为A，则对于建立框架的页面来说，A是Frames集合中的一个成员，而对于A中的页面来说，A相当于window对象。因些，虽然框架之间不存在从属关系，但可以通过它们的父页面（对象）建立各框架之间的关系。

如右图所示：框架之间能够进行相互控制与数据传送。

1）．在框架A中用的是最常用的框架控制方式，利用＜A TARGET＝“B” HREF=”URL”＞ 控制B框架中的页面重载。

2）．在框架B中，通过按钮的点击事件对框架C进行控制，这里的控制是通过DOM来实现的。(假设B中按钮Name值为“B1”)

控制C中的URL，在按钮的ONCLICK事件中加入以下代码：(VBScript)

sub b1_onclick

set Bframe = parent.B

Bframe.location.href = “URL”

End sub

控制C中的文本框内容，在按钮的ONCLICK事件中加入以下代码：(VBScript)

sub b1_onclick

set Bframe = parent.B

Brame.document.all.txt1.value = “刘念”

‘txt1是C框架中文本框的Value值

end sub

2．新的框架结构

如上图，我们定义了一个新的框架结构。在新的框架结构中，除了用来放置一、二级菜单的MENU1、MENU2和用来放置三级菜单及具体应用功能的Aapp之外，还增加了三个专门用来处理数据的框架（在上图中用虚线表示）。这三个框架不需要界面，在应用执行的时候是看不见的。

三个数据处理框架的与Aapp框架分工合作，完成具体的功能。

Aapp 针对具体功能的界面和专用控制脚本

Bfun 客户端公用函数和全局变量

Cbuf 数据集合存储缓冲区

Dcom 服务器端命令执行结果存储缓区

在系统中，根据生存周期按Bfun→Aapp→Cbuf→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%左右。