簡介
Active Server Page (ASP)應用程序的成功常常取決於對體系結構和設計這兩方面的取捨考慮到 ASP 技術的范圍之廣和當前應用程序固有的復雜性這種取捨是非常困難的本文中我將為您提供一些特定的指導方針以助您成功開發基於 ASP 的應用程序
我已將指導方針整理成一組開發原則在評估解決方案和技術時可以應用以下原則幫助您做出決策以下原則是我長期以來從成功的開發模式所得的經驗積累
原則 采用標准方法
建立命名約定並使目錄結構標准化可以幫助您大大提高 ASP 應用程序的可讀性和可維護性雖然目前尚無 ASP 應用程序的正式標准許多開發人員還是建立了一些通用方式在此我將與您共享一些更為通用的方式
因為 ASP 技術依靠腳本引擎進行工作而且腳本具有類型不嚴密的天性命名約定也很模糊在類型非常嚴密的語言中變量將按照它的實際類型進行聲明在使用 ASP 技術時通常按照處理變量的方式（而不是其實際數據類型）在 ASP 代碼中聲明變量例如在使用Visual Basic(R) Scripting Edition (VBScript)時盡管所有的 VBScript 變量都是 Variant你還是會將成功標志聲明為 bSuccess（b 代表布爾型）而不是 vSuccess（v 代表 Variant）
下表是一些通行的命名約定
變量前綴
前綴 使用的變量 變量示例
b or bln Boolean bSuccess
c or cur Currency cAmount
d or dbl Double dblQuantity
dt or dat Date and Time dtDate
f or flt Float fRatio
l or lng Long lMilliseconds
i or int Integer iCounter
s or str String sName
a or arr Array aUsers()
o or obj COM Object oPipeline
數據庫對象的變量前綴
前綴 使用的變量 變量示例
cnn Connection cnnPubs
rst Recordset rstAuthors
cmd Command cmdEmployee
fld Field fldLastName
范圍及前綴的用法
前綴 說明
g_ 創建於 Globalasa
m_ 對於 ASP 頁或在 Include 文件中是局部的
（沒有前綴） 非靜態變量對於過程來說前綴是局部的
Knowledge Base (KB) 中的一篇文章Q INFO: Microsoft Consulting Services Naming Conventions for Visual Basic（英文）對命名約定提供了真知灼見
盡可能采用目錄結構為您的各個應用程序部件提供始終如一的位置您應用程序的實際目錄結構當然由您自己決定但通常是將圖像文檔include 文件和組件分別放置在單獨的目錄中以下是簡單 ASP 應用程序目錄結構示例
目錄結構示例
\SimpleAspApp
\Docs
\Images
\Includes
一個好的目錄結構允許您有選擇地應用 NTFS 權限您還可以從 ASP 應用程序內部使用相對路徑例如可以使用以下代碼從位於 SimpleAspApp 目錄的 defaultasp 頁引用 Includes 目錄中的 include 文件 topasp
/includes/topasp
注意我的 include 文件的擴展名是 asp而不是 inc這樣做是出於安全方面的考慮而且使用 asp 擴展名（而不是 inc）還能夠在 Visual InterDev(R) 中使用彩色編碼
有關結構化 ASP 應用程序的其他一些提示和技巧請參閱文章ASP Conventions（英文）
原則 設計為在服務下運行
ASP 將在服務下運行設計 ASP 應用程序時您馬上會面臨在桌面應用程序中不會遇到的安全環境和線程問題在桌面環境中通常只處理作為交互式用戶運行的單線程執行而且有權訪問當前的桌面系統在Internet 信息服務 (IIS)中模擬不同用戶環境的多個客戶機線程調用您的應用程序而且您的應用程序被限於系統桌面
這對您來說意味著什麼？請學習 IIS 的安全模式還要提醒您僅因為某些東西能在 Visual Basic IDE 下能夠正常運行並不意味著它就能在 ASP 技術中安全運行Visual Basic IDE 並沒有准確地模擬運行時環境常見的設計錯誤包括在 ASP 技術中使用需要用戶界面的 OCX 控件使用對線程來說不安全的組件和使用要求特殊的用戶上下文的組件要避免的一個最簡單的問題就是從應用程序中試圖訪問 HKEY_CURRENT_USER (HKCU) 注冊表項（例如不要調用 Visual Basic 的 GetSetting 和 SaveSetting 函數它們都依賴於 HKCU）同樣不要出現需要用戶進行人機交互的消息框或其他對話框
以下文章是有關 ASP 技術中的安全和驗證問題的相當不錯的入門讀物
Authentication and Security for Internet Developers（英文）
Q INFO: Security Issues with Objects in ASP and ISAPI Extensions（英文）
原則 封裝業務邏輯
ASP 技術通過生成 HTML 輸出提供了表示服務簡而言之它會生成用戶界面您需要將商務邏輯從 ASP 表示腳本中分隔開來即使您不使用 COM 組件將業務邏輯從 ASP 代碼中分隔開來至少也要將業務邏輯分隔到函數和 include 文件中以提高可維護性可讀性和可重用性在需要排除故障和隔離問題時您還能體會模塊化設計方法的好處
調用腳本內部調用函數和方法可避免代碼亂作一團並能在 ASP 應用程序中添加結構下面舉例說明從 ASP 代碼中將邏輯分離到方法調用中
lt;% Main()
MyBizMethod()
Sub Main()
GetData()
DisplayData()
End Sub
%>
在使用包含 ASP 功能的技術時可以應用這一原則下面舉一個使用 Visual Basic WebClass 時的例子說明如何使用這一原則
因為 WebClass 本身引用 ASP 代碼生成 HTML所以您不要將業務邏輯直接置於 WebClass 內因為這是您的表示層不在 MTS/COM+ 下直接運行 WebClass
從 WebClass可以調用能運行在 MTS/COM+ 中的單獨業務組件
您可以決定創建自己的具有對 ASP 引用的 COM 組件而不是依賴於 WebClass 框架結構和額外的 WebClass 運行時開銷 — 您也可以使用 ASP 腳本直接將業務組件自動化
原則 盡晚獲取資源盡早釋放資源
常見的問題是從桌面系統到服務器的過渡許多具有桌面系統背景的開發人員從來沒有為服務器的一些問題和資源共享擔心過在傳統的桌面應用程序中連接到服務器是個耗時的過程為了改善用戶的體驗通常采用盡早獲取資源和推遲釋放資源的方法例如許多應用程序會在它的整個運行時間內始終連接著數據庫
這種方式在傳統的桌面應用程序中能夠正常工作其原因是用戶數量非常明確容易加以控制並且後端與前端緊密連接然而對於當前的 Web 應用程序這種方式已經不可行了其原因是有限的服務器資源將面對越來越多的用戶為了使您的應用程序能夠應付用戶的增加您需要盡晚獲取資源盡早釋放資源
共用有助於增加這一方式的有效性通過共用多個用戶能夠共享資源而且等待時間最少對服務器的影響也最小例如在處理數據庫時ODBC 連接共用和 OLEDB 資源共用可以實現從共用池中選擇連接最大程度地減少連接數據庫的開銷
有關共用 ADO 的詳細信息請參閱Pooling in Microsoft Data Access Components（英文）
原則 使用數據庫維護復雜的狀態
盡管 HTTP 協議是無狀態的ASP 開發人員還是會經常使用 ASP 功能內置的狀態保持機制例如使用 ASP 技術內置的 Application 對象開發人員所保存的資源能夠為應用程序的所有用戶共享通過使用 ASP 內置的 Session 對象開發人員只為單個用戶保存資源
盡管聽起來在 ASP 技術的 Session 對象中保存信息是一個非常方便的保持狀態的方式然而這一方式付出的代價太大而且它也可能成為對可伸縮性的最大的限制因素之一應用程序的可伸縮性本質上是隨著用戶數目的增長能夠繼續保持其性能的能力而對於每一用戶在會話超時或被放棄之前Session 對象都會消耗服務器的資源會話還會將您捆綁到一台服務器上從而限制您利用 Web 集群的功能請盡可能不要使用 ASP Session 對象進行狀態管理如果您完全沒有使用會話您就可以禁用 Web 應用程序的 Session 狀態（請參閱 IIS 文檔）否則您可以使用下述語句針對每一頁禁用 Session 狀態
<%@ENABLESESSIONSTATE=False %>
對於一些簡單的數據您可以使用 QueryString cookie 或隱藏的窗體域保持 ASP 請求間的狀態然後對於更為復雜的信息通常推薦您使用數據庫一般所采用的方式是生成某一特有的標識符然後發送到每一個發出請求的客戶機並保存為隱藏的窗體域在隨後的請求中這一特有的標識符被用於在數據庫中查找與該用戶相關的狀態信息這一方式提供了更高的可伸縮性和更為簡潔明了的代碼
有關使用 QueryString cookie 和隱藏的窗體域的詳細信息請參閱Q HOWTO: Persisting Values Without Sessions（英文）
原則 使用 ServerCreateObject 創建對象
在創建 ASP 技術的對象時您可以選擇 <OBJECT> 標記ServerCreateObject 和 CreateObject 三種方式每項技術的行為略有不同盡管在 IIS 中使用 <OBJECT> 標記或 CreateObject 比 ServerCreateObject 略具性能優勢我們一般還是推薦使用 ServerCreateObject 以便於 ASP 應用程序認知您的對象（注意在 IIS 中前兩項與 ServerCreateObject 相比已經沒有性能優勢
<OBJECT> 標記僅在調用第一個方法時才會創建組件因此能夠節省資源ServerCreateObject 使用 ASP 技術內置的 Server 對象創建組件實質上它只是執行了 CoCreateInstance但是 ASP 卻能夠認知這一對象同時還將調用 ASP 技術的傳統的 OnStartPage 和 OnEndPage（注意最好在 IIS 或者更高版本中使用 ObjectContext）如果您只是使用 CreateObject您將越過 ASP 技術而直接使用 Scripting 引擎
以下是一個可能出現的例外情況當您通過防火牆進行調用時您可能需要調用 CreateObject 而不是 ServerCreateObject詳細信息請參閱Q PRB: ServerCreateObject Fails when Object is Behind Firewall（英文）
原則 提供豐富的疑難解答信息
確保在您所有的 ASP 應用程序中都包含了錯誤處理過程而且確保您提供了有用的診斷信息我還沒有碰到有哪個人抱怨錯誤信息太具有說明性了請確保在錯誤日志中包含以下信息
用戶上下文（如果您正在使用組件您可以調用 GetUserName）
線程 ID（在組件中可以調用 GetCurrentThreadId）<
時間
完整的錯誤信息（包括編號來源和說明）
參數值
因為將在 ASP 下運行您可能希望將這些信息寫到文件或 NT 的事件日志您還可以創建記錄關鍵的應用程序事件的應用程序事件日志以備診斷應用程序錯誤時使用
以下文章提供了有關錯誤處理技術的詳細信息
Bulletproofing Your ASP Components（英文）Charles Alexander 著
Fitch & Mather Stocks: Web Application Design（英文）
Handling and Avoiding Web Page Errors Part : The Basics（英文）
Handling and Avoiding Web Page Errors Part : RunTime Errors（英文）
Handling and Avoiding Web Page Errors Part : An Ounce of Prevention（英文）
原則 測試性能可伸縮性和可靠性
浏覽器並不是准確的測試方式它只能向您展示應用程序可能的用途請針對您的應用程序設置特定的性能目標並使用 Web Application Stress Tool 等負載工具進行壓力測試您需要自己決定您的環境所能接受的條件以下是一些幫助您啟動測試過程的通用指導方針
通過測試 ASP 每秒鐘的請求數對性能進行測試並建立一個最小的阈值一般情況下不執行數據庫訪問的簡單 ASP 頁每秒鐘至少應返回 頁調用組件或訪問數據庫的頁每秒鐘至少返回 頁
向應用程序不停地追加用戶直到每秒鐘的請求數低於預先設置的阈值用這種方式測試可伸縮性
從 Web 集群中移去機器並檢查錯誤和故障情況以便測試可靠性
將測試環境與實際運行的環境相匹配甚至防火牆也不例外這聽起來代價很高但我曾經聽說過開發人員因為沒有考慮到防火牆而丟失了工作
有關使用 Web Application Stress Tool 測試 ASP 應用程序的詳細信息請參閱I Cant Stress It Enough Load Test Your ASP Application（英文）
原則 增加隔離性
使用隔離功能保護您的應用程序過程能夠極大地增強服務器的穩定性談到 Internet 應用程序是否使用隔離功能的後果可能會有巨大的差別一個是應用程序崩潰一個是服務器當機保護主 IIS 進程 (InetInfoexe) 通常會排在優先級列表的較高位置在您使用組件時這一點尤為突出
通常所采用的保護主 ISS 進程的技術是使 Web 應用程序運行在各自的內存空間中在 Internet Services Manager 中您可以針對每一個 Web 設置這一選項雖然因對進程進行編組而開銷的系統資源會對性能有些微的影響但對應用程序所起的保護作用值得付出這一代價 在 IIS 下您可以采用進程內 (inprocess) 和進程外（outofprocessOOP）兩種方式運行應用程序OOP 應用程序會運行在新的 Mtxexe 實例中在 IIS 下您還能使用其他的隔離選項可以將隔離級別設置為低（對 Inetinfoexe 來說是進程內應用程序）中（DllHostexe 共享實例）或高（Dllhostexe的非共享實例）
除了將 Web 應用程序隔離在它們自己的內存空間中之外您可能還希望隔離不信任的組件不信任的組件通常是在實際環境中沒有通過測試時間的考驗的組件您可以在 Server 包中運行這些組件這樣它們會運行在新的 Dllhostexe 實例中
一般而言如果要在性能和保護措施之間采取中庸之道方式如下在高隔離狀態運行 Web 應用程序在庫包中運行組件這種方式最大限度地減少了編組開支同時在進程之間提供了最強的保護作用
詳細信息請參閱文章Server Reliability Through Process Isolation（英文）
原則 不要濫用線程共用組
在 IIS 下針對每個受 MTS 管理的處理器ASP 的默認共用組是 個線程在 IIS 中默認值是 這就意味著每一線程都是一份潛在的寶貴資源能夠處理多個客戶機請求您同樣需要避免調用會出現阻塞的方法如進行大的數據庫調用如果您有要執行這種操作的工作它將阻止 ASP 應用程序將響應快速返回到客戶機則請考慮使用隊列功能例如在 NT 中可以使用 MSMQ在 Windows 中可以使用 Q 在 Windows 中可以使用 Queued Components（排隊組件）
在會話中不要存儲 Singlethreaded Apartment (STA) 組件這種方式的一個共同缺陷是會填滿會話范圍中的 Visual Basic 對象會將用戶鎖定到某一線程與線程共用組的目的背道而馳潛在的用戶會被阻塞在其他用戶的後面等待創建他們組件的線程變得有效您應該采用別的方式設計能基於每一頁進行創建和破壞的無狀態組件
From:http://tw.wingwit.com/Article/program/net/201311/12933.html
