WEB服务器多框架解决方案

t>【摘要】在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 如果一个功能在操作上存在多个步