web服务器多框架解决方案

精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 1 / 8WEB 服务器多框架解决方案 摘要在 INTRANET 上设计基于 WEB 的 MIS 时，大批量数据录入变成了操作上的瓶颈，并给 WEBSERVER 与 DATABASE造极大的负担。为解决这个问题，我们设计了多框架结构，将应用的功能进行细分，然后交给各框架分别完成，这种分工协作方式可以使操作界面上的数据实现受控的部分刷新，有效地减小了网络的数据传输量，缩短了各部分的处理时间，同时了也大大减轻了 WEBSERVER 与 DATABASE 的系统负担。多框架解决方案采用 ASP（ActiveXServerPages）及ADO(ActiveXDataObjects)完成与数据库的交互工作。采用DOM 技术解决和框架之间的协作问题。关键词：多框架*注：中讨论的方案中 WEB 服务器为 IIS4.0、客户端浏览器为 IE4.0 以上版本。一、问题的提出最初，我们采用 ASP 及 ADO 技术在 INTRANET 上设计基于 WEB 的 MIS（下文简称 MIS）时，沿用了以往设计 WEB 站点时的设计习惯。但随着设计的深入，我们发现，现有的系统结构无法承担大批量的数据录入工作，因此，必须重新构造系统的总体设计结构。MIS 与普通的 WEB 站点之间最大的区别在于处理信息的精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 2 / 8方式。普通 WEB 站点的主要功能是发布信息，采集信息只是它极小的一部分功能，而且这些信息采集功能也都是比较简单的。但对于 MIS 系统来说，信息的采集及维护工作占有比较高的比例，在这些信息采集功能中还存在一些较为复杂及大批量的数据录入功能，这些功能成为了系统中的设计难点。二、问题的分析当一个系统涉及到复杂及大批量的数据录入功能时，同时也就涉及到了响应速度及界面的问题。在以往的 C/S方式中，客户端的录入速度由录入员来控制，一般情况下，当录入员熟悉了操作方式之后，录入速度是不受系统限制的。但在 WEB 方式下，页面采用完全刷新方式，每次的交互操作至少要造成一个页面的刷新。这种刷新的工作不仅更新了数据，也将界面上的一些固定内容重新加载了一遍。对于普通用户来说，这种短时间的刷新并不会造成影响；但对于长时间进行操作的录入员来说，录入一条数据就要等待一段时间（这一段时间可能是 2-3 秒，也可能是十几秒甚至几分钟） ，是绝对不能接受的。即使，网络有足够的带宽，页面的重载也会造成一种闪动的效果，这种一闪一闪的刷新造成录入员必须重新识别页面上的各种元素，不仅也会拖慢了他们的录入速度，还造成眼睛的快速疲劳。三、解决方案精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 3 / 8如果能够“不”刷新页面而“快速更新”页面中的数据，问题应该能够解决了。而且页面由于没有刷新，一些必须由服务器保存的状态信息也能够在客户端保存下来了，从而减轻服务器的负担。那么如何达到这个目标呢？下面将详细讨论。1设计思路首先，我们确立采用多框架建立页面。框架(Frames)其实不是什么新东西，许多站点上都用它来完成显示固定标题及菜单的功能。采用框架能够避免一些页面的重复访问。但是如果结合使用 DOM（Documentobjectsmodel)，框架可以完成许多细致的工作。按照 DOM 的定义，框架可以被当作一个对象。假设我们建立了一个框架，并给它取名为 A，则对于建立框架的页面来说，A 是 Frames 集合中的一个成员，而对于 A 中的页面来说，A 相当于 window 对象。因些，虽然框架之间不存在从属关系，但可以通过它们的父页面（对象）建立各框架之间的关系。如右图所示：框架之间能够进行相互控制与数据传送。1） 在框架 A 中用的是最常用的框架控制方式，利用ATARGET“B”HREF=”URL”控制 B 框架中的页面重载。精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 4 / 82） 在框架 B 中，通过按钮的点击事件对框架 C 进行控制，这里的控制是通过 DOM 来实现的。(假设 B 中按钮Name 值为“B1”)控制 C 中的 URL，在按钮的 ONCLICK 事件中加入以下代码：(VBScript)subb1_onclicksetBframe=parent.BBframe.location.href=“URL”Endsub控制 C 中的文本框内容，在按钮的 ONCLICK 事件中加入以下代码：(VBScript)subb1_onclicksetBframe=parent.BBrame.document.all.txt1.value=“刘念”txt1 是 C 框架中文本框的 Value 值endsub2新的框架结构如上图，我们定义了一个新的框架结构。在新的框架结构中，除了用来放置一、二级菜单的 MENU1、MENU2 和用来放置三级菜单及具体应用功能的 Aapp精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 5 / 8之外，还增加了三个专门用来处理数据的框架（在上图中用虚线表示） 。这三个框架不需要界面，在应用执行的时候是看不见的。三个数据处理框架的与 Aapp 框架分工合作，完成具体的功能。Aapp 针对具体功能的界面和专用控制脚本Bfun 客户端公用函数和全局变量Cbuf 数据集合存储缓冲区Dcom 服务器端命令执行结果存储缓区在系统中，根据生存周期按 BfunAappCbufDcom的顺序从大到小存放变量和数据对象。具体约定如下：Bfun 系统级全局变量。如：用户的登录信息和操作记录。Aapp 功能级全局变量。如：步骤状态参数、功能常数。Cbuf 如果一个功能在操作上存在多个步骤，在其中不确定的连续几个步骤中会用到的公共数据就保存在这个框架中，如一个缓冲表。Dcom 针对 Cbuf，此框架只保存在多个步骤中的一步里需要用到的数据。如：函数计算结果。Cbuf 及 Dcom 框架中保存的数据主要从服务器上取得。3程序流程说明精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 6 / 8在一个具体的功能中，Aapp 对整个程序流程进行控制。Aapp 通过对象关系取得 Bfun 中的变量值或调用 Bfun 中的函数。而 Cbuf 及 Dcom 中会包含一个完整的服务器端处理流程，AAPP 在适当的时候将业务流程控制权交给 Cbuf 或Dcom，Cbuf 或 Dcom 在流程执行完成之后必须将流程控制权还给 Aapp。由于借助了 DOM 中对象的方法与触发事件,Aapp中可以实现部分数据更新,就象一个 C/S 中的客户端程序。如上图，Cbuf 与 Dcom 负担了与 WEBSERVER 及DATABASE 的数据交换工作，使 Aapp 在第一次被装入后就只需要在客户端浏览器中运行。这样，Aapp 中的主要界面就不需要进行刷新，避免了页面刷新时造成的延迟和闪烁问题。而 Cbuf 与 Dcom 中可以只，根据约定格式返回数据和一个事件触发脚本，数据传输量可以根据需要降到最小，又因为 Cbuf 与 Dcom 没有可视界，因此在浏览器中的加载速度也是最快的。另外，Bfun 中保存了大部分的函数和变量，即使 Aapp 的页面需要重载，也只需要重载该页面专用的一部分内容。4数据存储格式约定将数据写入 Aapp 界面中的方式有两种：一种是在 Cbuf 与 Dcom 定制脚本将数据写到 Aapp 中；另一种则是由 Aapp 中的脚本读取 Cbuf 与 Dcom 中的数精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 7 / 8据再写到自已的界面上。两种方法最终都要保证 Aapp 取得程序流程控制权。当从服务器上取到的数据比较少时（比如出错提出示信息） ，前一种方法是可行的。但当从服务器取回的是一个数据集合（比如多行的记录集）时，前一种方法会造成控制脚本太长的问题，而且灵活性也不如后一种方法。而且按照各框架的分工，数据的控制功能应该由 Aapp 去完成。因此后一种方法是数据控制的主要方法，但采用后一种方法必须在 Cbuf 与 Dcom 中定义一个数据格式。在数据量少的时候，可以用变量保存数据，变量名可以在提交 URL 时定义，也可以使用默认变量名。两种定义方式性能差别不大，具体采用那一种可以根据个人喜好而定。在数据量比较大时，最常见的情况是在服务器上取回了一个若干行的记录集。这时可以采用表格保存数据。具体格式如下：假设在提交 ASP 文件的 URL 时定义的表格对象名为rsTest，则会返回两个表格对象 rsTest 和 rsTestStru。RsTestStru 用来存放记录集的列属性数据。这个表由固定的五列组成：1ID 列顺序号2NAME 名称精品文档2016 全新精品资料-全新公文范文 -全程指导写作 独家原创 8 / 83TYPE 数据类型4LENGTH 长度5PREC 小数位RsTest 用来存放记录集的各行数据。在 DOM 中，表格对象的行和列都有属于相应的对象集合。通过指定行和列的序号能够很准确的定位到任何一个数据元素，再结合 innerText 属性便可以取出想要的数据。但 DOM 并没有给出对表格元素进行排序及查找的方法，因此我们必须自己编写这方面的函数脚本。对于实际的 WEB-MIS，还要考虑 ASP 及数据库方面的程序优化问题；一些额外的功能，如打印控制等，仍需要借助 Acti