【摘要】在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
= “URL”
End sub
控制C中的文字框內容，在按鈕的ONCLICK事件中加入以下程式碼：(VBScript)
sub b1_onclick
set Bframe = parent.B
e = “劉念”
‘txt1是C框架中文字框的Value值
end sub
2．新的框架結構
如上圖，我們定義了一個新的框架結構。在新的框架結構中，除了用來放置一、二級選單的MENU1、MENU2和用來放置三級選單及具體應用功能的Aapp之外，還增加了三個專門用來處理資料的框架（在上圖中用虛線表示）。這三個框架不需要介面，在應用執行的時候是看不見的。
三個資料處理框架的與Aapp框架分工合作，完成具體的功能。
Aapp 針對具體功能的介面和專用控制指令碼
Bfun 客戶端公用函式和全域性變數
Cbuf 資料集合儲存緩衝區
Dcom 伺服器端命令執行結果儲存緩區
在系統中，根據生存週期按Bfun→Aapp→Cbu
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%左右。
