基于WEB服務(wù)器多框架解決方案
【摘要】在INTRANET上設計基于WEB的MIS時(shí),大批量數據錄入變成了操作上的瓶頸,并給WEB SERVER與DATABASE造極大的負擔。
本文引用地址:http://dyxdggzs.com/article/202158.htm為解決這個(gè)問(wèn)題,我們設計了多框架結構,將應用的功能進(jìn)行細分,然后交給各框架分別完成,這種分工協(xié)作方式可以使操作界面上的數據實(shí)現受控的部分刷新,有效地減小了網(wǎng)絡(luò )的數據傳輸量,縮短了各部分的處理時(shí)間,同時(shí)了也大大減輕了WEB SERVER與DATABASE的系統負擔。
多框架解決方案采用ASP(ActiveX Server Pages)及ADO(ActiveX Data Objects)完成與數據庫的交互工作。采用DOM技術(shù)解決和框架之間的協(xié)作問(wèn)題。
一、問(wèn)題的提出
最初,我們采用ASP及ADO技術(shù)在INTRANET上設計基于WEB的MIS(下文簡(jiǎn)稱(chēng)MIS)時(shí),沿用了以往設計WEB站點(diǎn)時(shí)的設計習慣。但隨著(zhù)設計的深入,我們發(fā)現,現有的系統結構無(wú)法承擔大批量的數據錄入工作,因此,必須重新構造系統的總體設計結構。
MIS與普通的WEB站點(diǎn)之間最大的區別在于處理信息的方式。普通WEB站點(diǎn)的主要功能是發(fā)布信息,采集信息只是它極小的一部分功能,而且這些信息采集功能也都是比較簡(jiǎn)單的。但對于MIS系統來(lái)說(shuō),信息的采集及維護工作占有比較高的比例,在這些信息采集功能中還存在一些較為復雜及大批量的數據錄入功能,這些功能成為了系統中的設計難點(diǎn)。
二、問(wèn)題的分析
當一個(gè)系統涉及到復雜及大批量的數據錄入功能時(shí),同時(shí)也就涉及到了響應速度及界面的問(wèn)題。在以往的C/S方式中,客戶(hù)端的錄入速度由錄入員來(lái)控制,一般情況下,當錄入員熟悉了操作方式之后,錄入速度是不受系統限制的。但在WEB方式下,頁(yè)面采用完全刷新方式,每次的交互操作至少要造成一個(gè)頁(yè)面的刷新。這種刷新的工作不僅更新了數據,也將界面上的一些固定內容重新加載了一遍。對于普通用戶(hù)來(lái)說(shuō),這種短時(shí)間的刷新并不會(huì )造成影響;但對于長(cháng)時(shí)間進(jìn)行操作的錄入員來(lái)說(shuō),錄入一條數據就要等待一段時(shí)間(這一段時(shí)間可能是2-3秒,也可能是十幾秒甚至幾分鐘),是絕對不能接受的。即使,網(wǎng)絡(luò )有足夠的帶寬,頁(yè)面的重載也會(huì )造成一種閃動(dòng)的效果,這種一閃一閃的刷新造成錄入員必須重新識別頁(yè)面上的各種元素,不僅也會(huì )拖慢了他們的錄入速度,還造成眼睛的快速疲勞。
三、解決方案
如果能夠“不”刷新頁(yè)面而“快速更新”頁(yè)面中的數據,問(wèn)題應該能夠解決了。而且頁(yè)面由于沒(méi)有刷新,一些必須由服務(wù)器保存的狀態(tài)信息也能夠在客戶(hù)端保存下來(lái)了,從而減輕服務(wù)器的負擔。那么如何達到這個(gè)目標呢?下面將詳細討論。
1.設計思路
首先,我們確立采用多框架建立頁(yè)面??蚣?Frames)其實(shí)不是什么新東西,許多站點(diǎn)上都用它來(lái)完成顯示固定標題及菜單的功能。采用框架能夠避免一些頁(yè)面的重復訪(fǎng)問(wèn)。但是如果結合使用DOM(Document objects model),框架可以完成許多細致的工作。
按照DOM的定義,框架可以被當作一個(gè)對象。假設我們建立了一個(gè)框架,并給它取名為A,則對于建立框架的頁(yè)面來(lái)說(shuō),A是Frames集合中的一個(gè)成員,而對于A(yíng)中的頁(yè)面來(lái)說(shuō),A相當于window對象。因些,雖然框架之間不存在從屬關(guān)系,但可以通過(guò)它們的父頁(yè)面(對象)建立各框架之間的關(guān)系。
如右圖所示:框架之間能夠進(jìn)行相互控制與數據傳送。
1).在框架A中用的是最常用的框架控制方式,利用<A TARGET=“B” HREF=”URL”> 控制B框架中的頁(yè)面重載。
2).在框架B中,通過(guò)按鈕的點(diǎn)擊事件對框架C進(jìn)行控制,這里的控制是通過(guò)DOM來(lái)實(shí)現的。(假設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.新的框架結構
如上圖,我們定義了一個(gè)新的框架結構。在新的框架結構中,除了用來(lái)放置一、二級菜單的MENU1、MENU2和用來(lái)放置三級菜單及具體應用功能的Aapp之外,還增加了三個(gè)專(zhuān)門(mén)用來(lái)處理數據的框架(在上圖中用虛線(xiàn)表示)。這三個(gè)框架不需要界面,在應用執行的時(shí)候是看不見(jiàn)的。
三個(gè)數據處理框架的與Aapp框架分工合作,完成具體的功能。
Aapp 針對具體功能的界面和專(zhuān)用控制腳本
Bfun 客戶(hù)端公用函數和全局變量
Cbuf 數據集合存儲緩沖區
Dcom 服務(wù)器端命令執行結果存儲緩區
在系統中,根據生存周期按Bfun→Aapp→Cbuf→Dcom的順序從大到小存放變量和數據對象。具體約定如下:
Bfun 系統級全局變量。如:用戶(hù)的登錄信息和操作記錄。
Aapp 功能級全局變量。如:步驟狀態(tài)參數、功能常數。
Cbuf 如果一個(gè)功能在操作上存在多個(gè)步驟,在其中不確定的連續幾個(gè)步驟中會(huì )用到的公共數據就保存在這個(gè)
框架中,如一個(gè)緩沖表。
Dcom 針對Cbuf,此框架只保存在多個(gè)步驟中的一步里需要用到的數據。如:函數計算結果。
Cbuf及Dcom框架中保存的數據主要從服務(wù)器上取得。
3.程序流程說(shuō)明
在一個(gè)具體的功能中,Aapp對整個(gè)程序流程進(jìn)行控制。Aapp通過(guò)對象關(guān)系取得Bfun中的變量值或調用Bfun中的函數。而Cbuf及Dcom中會(huì )包含一個(gè)完整的服務(wù)器端處理流程,AAPP在適當的時(shí)候將業(yè)務(wù)流程控制權交給Cbuf或Dcom,Cbuf或Dcom在流程執行完成之后必須將流程控制權還給Aapp。由于借助了DOM中對象的方法與觸發(fā)事件,Aapp中可以實(shí)現部分數據更新,就象一個(gè)C/S中的客戶(hù)端程序。
如上圖,Cbuf與Dcom負擔了與WEB SERVER及DATABASE的數據交換工作,使Aapp在第一次被裝入后就只需要在客戶(hù)端瀏覽器中運行。這樣,Aapp中的主要界面就不需要進(jìn)行刷新,避免了頁(yè)面刷新時(shí)造成的延遲和閃爍問(wèn)題。而Cbuf與Dcom中可以只根據約定格式返回數據和一個(gè)事件觸發(fā)腳本,數據傳輸量可以根據需要降到最小,又因為Cbuf與Dcom沒(méi)有可視界,因此在瀏覽器中的加載速度也是最快的。另外,Bfun中保存了大部分的函數和變量,即使Aapp的頁(yè)面需要重載,也只需要重載該頁(yè)面專(zhuān)用的一部分內容。
4.數據存儲格式約定
將數據寫(xiě)入Aapp界面中的方式有兩種:
一種是在Cbuf與Dcom定制腳本將數據寫(xiě)到Aapp中;
另一種則是由Aapp中的腳本讀取Cbuf與Dcom中的數據再寫(xiě)到自已的界面上。
兩種方法最終都要保證Aapp取得程序流程控制權。
當從服務(wù)器上取到的數據比較少時(shí)(比如出錯提出示信息),前一種方法是可行的。但當從服務(wù)器取回的是一個(gè)數據集合(比如多行的記錄集)時(shí),前一種方法會(huì )造成控制腳本太長(cháng)的問(wèn)題,而且靈活性也不如后一種方法。而且按照各框架的分工,數據的控制功能應該由Aapp去完成。因此后一種方法是數據控制的主要方法,但采用后一種方法必須在Cbuf與Dcom中定義一個(gè)數據格式。
在數據量少的時(shí)候,可以用變量保存數據,變量名可以在提交URL時(shí)定義,也可以使用默認變量名。兩種定義方式性能差別不大,具體采用那一種可以根據個(gè)人喜好而定。
在數據量比較大時(shí),最常見(jiàn)的情況是在服務(wù)器上取回了一個(gè)若干行的記錄集。這時(shí)可以采用表格保存數據。具體格式如下:
假設在提交ASP文件的URL時(shí)定義的表格對象名為rsTest,則會(huì )返回兩個(gè)表格對象rsTest和rsTestStru。
RsTestStru用來(lái)存放記錄集的列屬性數據。這個(gè)表由固定的五列組成:
1.ID 列順序號
2.NAME 名稱(chēng)
3.TYPE 數據類(lèi)型
4.LENGTH 長(cháng)度
5.PREC 小數位
RsTest用來(lái)存放記錄集的各行數據。
在DOM中,表格對象的行和列都有屬于相應的對象集合。通過(guò)指定行和列的序號能夠很準確的定位到任何一個(gè)數據元素,再結合innerText屬性便可以取出想要的數據。但DOM并沒(méi)有給出對表格元素進(jìn)行排序及查找的方法,因此我們必須自己編寫(xiě)這方面的函數腳本。
對于實(shí)際的WEB-MIS,還要考慮ASP及數據庫方面的程序優(yōu)化問(wèn)題;一些額外的功能,如打印控制等,仍需要借助ActiveX或Java applet來(lái)實(shí)現,這里不作討論。
四、應用實(shí)例
本方案在“深圳市自來(lái)水公司管理信息系統(SW-MIS)”的“抄表收費分系統”中獲得了應用,“抄表數據錄入”功能在采用本方案進(jìn)行優(yōu)化后,在50個(gè)并發(fā)用戶(hù)的測試中達到了不少于10條/(用戶(hù)*分鐘)的錄入速度。而且WEB SERVER與SQL SERVER的CPU占用率能夠始終保持在10%左右。
更多計算機與外設信息請關(guān)注:21ic計算機與外設頻道
評論