WEB服务器多框架解决方案

WEB 服务器多框架解决方案服务器多框架解决方案 摘要 在 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 站点之间最大的区别在于处理信息的方式 普通 WEB 站点的主要功能是发布信息 采集信息只是它极小的 一部分功能 而且这些信息采集功能也都是比较简单的 但对 于 MIS 系统来说 信息的采集及维护工作占有比较高的比例 在这些信息采集功能中还存在一些较为复杂及大批量的数据录 入功能 这些功能成为了系统中的设计难点 二 问题的分析 当一个系统涉及到复杂及大批量的数据录入功能时 同时也 就涉及到了响应速度及界面的问题 在以往的 C S 方式中 客 户端的录入速度由录入员来控制 一般情况下 当录入员熟悉 了操作方式之后 录入速度是不受系统限制的 但在 WEB 方式 下 页面采用完全刷新方式 每次的交互操作至少要造成一个 页面的刷新 这种刷新的工作不仅更新了数据 也将界面上的 一些固定内容重新加载了一遍 对于普通用户来说 这种短时 间的刷新并不会造成影响 但对于长时间进行操作的录入员来 说 录入一条数据就要等待一段时间 这一段时间可能是 2 3 秒 也可能是十几秒甚至几分钟 是绝对不能接受的 即使 网络有足够的带宽 页面的重载也会造成一种闪动的效果 这 种一闪一闪的刷新造成录入员必须重新识别页面上的各种元素 不仅也会拖慢了他们的录入速度 还造成眼睛的快速疲劳 三 解决方案 如果能够 不 刷新页面而 快速更新 页面中的数据 问 题应该能够解决了 而且页面由于没有刷新 一些必须由服务 器保存的状态信息也能够在客户端保存下来了 从而减轻服务 器的负担 那么如何达到这个目标呢 下面将详细讨论 1 设计思路 首先 我们确立采用多框架建立页面 框架 Frames 其实不是 什么新东西 许多站点上都用它来完成显示固定标题及菜单的 功能 采用框架能够避免一些页面的重复访问 但是如果结合 使用 DOM Documentobjectsmodel 框架可以完成许多细致的 工作 按照DOM 的定义 框架可以被当作一个对象 假设我们建立 了一个框架 并给它取名为 A 则对于建立框架的页面来说 A 是 Frames 集合中的一个成员 而对于 A 中的页面来说 A 相 当于 window 对象 因些 虽然框架之间不存在从属关系 但 可以通过它们的父页面 对象 建立各框架之间的关系 如右图所示 框架之间能够进行相互控制与数据传送 1 在框架 A 中用的是最常用的框架控制方式 利用 ATARGET B HREF URL 控制 B 框架中的页面重载 2 在框架 B 中 通过按钮的点击事件对框架 C 进行控制 这里的控制是通过 DOM 来实现的 假设 B 中按钮 Name 值为 B1 控制C 中的 URL 在按钮的 ONCLICK 事件中加入以下代码 VBScript subb1 onclick setBframe parent B Bframe location href URL Endsub 控制C 中的文本框内容 在按钮的 ONCLICK 事件中加入以下 代码 VBScript subb1 onclick setBframe parent B Brame document all txt1 value 刘念 txt1 是 C 框架中文本框的 Value 值 endsub 2 新的框架结构 如上图 我们定义了一个新的框架结构 在新的框架结构中 除了用来放置 一 二级菜单的MENU 1 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 负担了与 WEBSERVER 及 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 及数据库方面的程序优 化问题 一些额外的功能 如打印控制等 仍需