簡介

“Active Server Page (ASP)”應(yīng)用程序的成功常常取決于對體系結(jié)構(gòu)和設(shè)計這兩方面的取舍?？紤]到 ASP 技術(shù)的范圍之廣和當前應(yīng)用程序固有的復雜性，這種取舍是非常困難的。本文中，我將為您提供一些特定的指導方針，以助您成功開發(fā)基于 ASP 的應(yīng)用程序。

我已將指導方針整理成一組開發(fā)原則。在評估解決方案和技術(shù)時，可以應(yīng)用以下原則幫助您做出決策。以下原則是我長期以來從成功的開發(fā)模式所得的經(jīng)驗積累。

原則 1：采用標準方法

建立命名約定并使目錄結(jié)構(gòu)標準化，可以幫助您大大提高 ASP 應(yīng)用程序的可讀性和可維護性。雖然目前尚無 ASP 應(yīng)用程序的正式標準，許多開發(fā)人員還是建立了一些通用方式。在此，我將與您共享一些更為通用的方式。

因為 ASP 技術(shù)依靠腳本引擎進行工作，而且腳本具有類型不嚴密的天性，命名約定也很模糊。在類型非常嚴密的語言中，變量將按照它的實際類型進行聲明。在使用 ASP 技術(shù)時，通常按照處理變量的方式（而不是其實際數(shù)據(jù)類型）在 ASP 代碼中聲明變量。例如，在使用“Visual Basic(R) Scripting Edition (VBScript)”時，盡管所有的 VBScript 變量都是 Variant，你還是會將成功標志聲明為 bSuccess（b 代表布爾型），而不是 vSuccess（v 代表 Variant）。

下表是一些通行的命名約定。

變量前綴：

數(shù)據(jù)庫對象的變量前綴：

范圍及前綴的用法：

Knowledge Base (KB) 中的一篇文章“Q110264 INFO: Microsoft Consulting Services Naming Conventions for Visual Basic”（英文）對命名約定提供了真知灼見。

盡可能采用目錄結(jié)構(gòu)為您的各個應(yīng)用程序部件提供始終如一的位置。您應(yīng)用程序的實際目錄結(jié)構(gòu)當然由您自己決定，但通常是將圖像、文檔、include 文件和組件分別放置在單獨的目錄中。以下是簡單 ASP 應(yīng)用程序目錄結(jié)構(gòu)示例。

目錄結(jié)構(gòu)示例：

\SimpleAspApp
 \Docs
 \Images
 \Includes

一個好的目錄結(jié)構(gòu)允許您有選擇地應(yīng)用 NTFS 權(quán)限。您還可以從 ASP 應(yīng)用程序內(nèi)部使用相對路徑。例如，可以使用以下代碼，從位于 SimpleAspApp 目錄的 default.asp 頁，引用 Includes 目錄中的 include 文件 top.asp：

./includes/top.asp

注意我的 include 文件的擴展名是 .asp，而不是 .inc。這樣做是出于安全方面的考慮，而且使用 .asp 擴展名（而不是 .inc），還能夠在 Visual InterDev(R) 中使用彩色編碼。

有關(guān)結(jié)構(gòu)化 ASP 應(yīng)用程序的其他一些提示和技巧，請參閱文章“ASP Conventions”（英文）。

原則 2：設(shè)計為在服務(wù)下運行

ASP 將在服務(wù)下運行。設(shè)計 ASP 應(yīng)用程序時，您馬上會面臨在桌面應(yīng)用程序中不會遇到的安全環(huán)境和線程問題。在桌面環(huán)境中，通常只處理作為交互式用戶運行的單線程執(zhí)行，而且有權(quán)訪問當前的桌面系統(tǒng)。在“Internet 信息服務(wù) (IIS)”中，模擬不同用戶環(huán)境的多個客戶機線程調(diào)用您的應(yīng)用程序，而且您的應(yīng)用程序被限于“系統(tǒng)”桌面。

這對您來說意味著什么？請學習 IIS 的安全模式。還要提醒您：僅因為某些東西能在 Visual Basic IDE 下能夠正常運行，并不意味著它就能在 ASP 技術(shù)中安全運行。Visual Basic IDE 并沒有準確地模擬運行時環(huán)境。常見的設(shè)計錯誤包括：在 ASP 技術(shù)中使用需要用戶界面的 .OCX 控件，使用對線程來說不安全的組件，和使用要求特殊的用戶上下文的組件。要避免的一個最簡單的問題，就是從應(yīng)用程序中試圖訪問 HKEY_CURRENT_USER (HKCU) 注冊表項（例如，不要調(diào)用 Visual Basic 的 GetSetting 和 SaveSetting 函數(shù)，它們都依賴于 HKCU）。同樣，不要出現(xiàn)需要用戶進行人機交互的消息框或其他對話框。

以下文章是有關(guān) ASP 技術(shù)中的安全和驗證問題的相當不錯的入門讀物：

• “Authentication and Security for Internet Developers”（英文）
• “Q172925 INFO: Security Issues with Objects in ASP and ISAPI Extensions”（英文）

原則 3：封裝商務(wù)邏輯

ASP 技術(shù)通過生成 HTML 輸出提供了表示服務(wù)。簡而言之，它會生成用戶界面。您需要將商務(wù)邏輯從 ASP 表示腳本中分隔開來。即使您不使用 COM 組件將商務(wù)邏輯從 ASP 代碼中分隔開來，至少也要將商務(wù)邏輯分隔到函數(shù)和 include 文件中，以提高可維護性、可讀性和可重用性。在需要排除故障和隔離問題時，您還能體會模塊化設(shè)計方法的好處。

調(diào)用腳本內(nèi)部調(diào)用函數(shù)和方法，可避免代碼亂作一團，并能在 ASP 應(yīng)用程序中添加結(jié)構(gòu)。下面舉例說明從 ASP 代碼中，將邏輯分離到方法調(diào)用中：

 lt;% Main()
 MyBizMethod()
 ...
 Sub Main()
 GetData()
 DisplayData()
 End Sub
%>

在使用包含 ASP 功能的技術(shù)時，可以應(yīng)用這一原則。下面舉一個使用 Visual Basic WebClass 時的例子，說明如何使用這一原則：

• 因為 WebClass 本身引用 ASP 代碼生成 HTML，所以您不要將商務(wù)邏輯直接置于 WebClass 內(nèi)。因為這是您的表示層，不在 MTS/COM+ 下直接運行 WebClass。
• 從 WebClass，可以調(diào)用能運行在 MTS/COM+ 中的單獨商務(wù)組件。
• 您可以決定創(chuàng)建自己的、具有對 ASP 引用的 COM 組件，而不是依賴于 WebClass 框架結(jié)構(gòu)和額外的 WebClass 運行時開銷 — 您也可以使用 ASP 腳本直接將商務(wù)組件自動化。

原則 4：盡晚獲取資源，盡早釋放資源

常見的問題是，從桌面系統(tǒng)到服務(wù)器的過渡。許多具有桌面系統(tǒng)背景的開發(fā)人員從來沒有為服務(wù)器的一些問題和資源共享擔心過。在傳統(tǒng)的桌面應(yīng)用程序中，連接到服務(wù)器是個耗時的過程。為了改善用戶的體驗，通常采用盡早獲取資源和推遲釋放資源的方法。例如，許多應(yīng)用程序會在它的整個運行時間內(nèi)始終連接著數(shù)據(jù)庫。

這種方式在傳統(tǒng)的桌面應(yīng)用程序中能夠正常工作其原因是用戶數(shù)量非常明確，容易加以控制，并且后端與前端緊密連接。然而，對于當前的 Web 應(yīng)用程序，這種方式已經(jīng)不可行了，其原因是有限的服務(wù)器資源將面對越來越多的用戶。為了使您的應(yīng)用程序能夠應(yīng)付用戶的增加，您需要盡晚獲取資源，盡早釋放資源。

共用有助于增加這一方式的有效性。通過共用，多個用戶能夠共享資源，而且等待時間最少，對服務(wù)器的影響也最小。例如，在處理數(shù)據(jù)庫時，ODBC 連接共用和 OLEDB 資源共用可以實現(xiàn)從共用池中選擇連接，最大程度地減少連接數(shù)據(jù)庫的開銷。

有關(guān)共用 ADO 的詳細信息，請參閱“Pooling in Microsoft Data Access Components”（英文）。

原則 5：使用數(shù)據(jù)庫維護復雜的狀態(tài)

盡管 HTTP 協(xié)議是無狀態(tài)的，ASP 開發(fā)人員還是會經(jīng)常使用 ASP 功能內(nèi)置的狀態(tài)保持機制。例如，使用 ASP 技術(shù)內(nèi)置的 Application 對象，開發(fā)人員所保存的資源能夠為應(yīng)用程序的所有用戶共享。通過使用 ASP 內(nèi)置的 Session 對象，開發(fā)人員只為單個用戶保存資源。

盡管聽起來在 ASP 技術(shù)的 Session 對象中保存信息是一個非常方便的保持狀態(tài)的方式，然而這一方式付出的代價太大，而且它也可能成為對可伸縮性的最大的限制因素之一。應(yīng)用程序的可伸縮性本質(zhì)上是隨著用戶數(shù)目的增長能夠繼續(xù)保持其性能的能力。而對于每一用戶，在會話超時或被放棄之前，Session 對象都會消耗服務(wù)器的資源。會話還會將您捆綁到一臺服務(wù)器上，從而限制您利用 Web 集群的功能。請盡可能不要使用 ASP Session 對象進行狀態(tài)管理。如果您完全沒有使用會話，您就可以禁用 Web 應(yīng)用程序的 Session 狀態(tài)（請參閱 IIS 文檔）。否則，您可以使用下述語句，針對每一頁禁用 Session 狀態(tài)：

<%@ENABLESESSIONSTATE=False %>

對于一些簡單的數(shù)據(jù)，您可以使用 QueryString cookie 或隱藏的窗體域保持 ASP 請求間的狀態(tài)。然后，對于更為復雜的信息，通常推薦您使用數(shù)據(jù)庫。一般所采用的方式是生成某一特有的標識符，然后發(fā)送到每一個發(fā)出請求的客戶機，并保存為隱藏的窗體域。在隨后的請求中，這一特有的標識符被用于在數(shù)據(jù)庫中查找與該用戶相關(guān)的狀態(tài)信息。這一方式提供了更高的可伸縮性和更為簡潔明了的代碼。

有關(guān)使用 QueryString cookie 和隱藏的窗體域的詳細信息，請參閱“Q175167 HOWTO: Persisting Values Without Sessions”（英文）。

原則 6：使用 Server.CreateObject 創(chuàng)建對象

在創(chuàng)建 ASP 技術(shù)的對象時，您可以選擇 <OBJECT> 標記、Server.CreateObject 和 CreateObject 三種方式。每項技術(shù)的行為略有不同。盡管在 IIS 4.0 中，使用 <OBJECT> 標記或 CreateObject 比 Server.CreateObject 略具性能優(yōu)勢，我們一般還是推薦使用 Server.CreateObject， 以便于 ASP 應(yīng)用程序認知您的對象。（注意在 IIS 5.0 中，前兩項與 Server.CreateObject 相比，已經(jīng)沒有性能優(yōu)勢。）

<OBJECT> 標記僅在調(diào)用第一個方法時才會創(chuàng)建組件，因此能夠節(jié)省資源。Server.CreateObject 使用 ASP 技術(shù)內(nèi)置的 Server 對象創(chuàng)建組件。實質(zhì)上，它只是執(zhí)行了 CoCreateInstance，但是 ASP 卻能夠認知這一對象。同時，還將調(diào)用 ASP 技術(shù)的傳統(tǒng)的 OnStartPage 和 OnEndPage。（注意最好在 IIS 4.0 或者更高版本中使用 ObjectContext）。如果您只是使用 CreateObject，您將越過 ASP 技術(shù)而直接使用 Scripting 引擎。

以下是一個可能出現(xiàn)的例外情況：當您通過防火墻進行調(diào)用時，您可能需要調(diào)用 CreateObject 而不是 Server.CreateObject。詳細信息，請參閱“Q193230 - PRB: Server.CreateObject Fails when Object is Behind Firewall”（英文）。

原則 7：提供豐富的疑難解答信息

確保在您所有的 ASP 應(yīng)用程序中都包含了錯誤處理過程。而且，確保您提供了有用的診斷信息。我還沒有碰到有哪個人抱怨錯誤信息太具有說明性了。請確保在錯誤日志中包含以下信息：

• 用戶上下文（如果您正在使用組件，您可以調(diào)用 GetUserName）
• 線程 ID（在組件中，可以調(diào)用 GetCurrentThreadId）<
• 時間
• 完整的錯誤信息（包括編號、來源和說明）
• 參數(shù)值

因為將在 ASP 下運行，您可能希望將這些信息寫到文件或 NT 的事件日志。您還可以創(chuàng)建記錄關(guān)鍵的應(yīng)用程序事件的應(yīng)用程序事件日志，以備診斷應(yīng)用程序錯誤時使用。

以下文章提供了有關(guān)錯誤處理技術(shù)的詳細信息：

• “Bulletproofing Your ASP Components”（英文），Charles Alexander 著
• “Fitch & Mather Stocks: Web Application Design”（英文）
• “Handling and Avoiding Web Page Errors, Part 1: The Basics”（英文）
• “Handling and Avoiding Web Page Errors, Part 2: Run-Time Errors”（英文）
• “Handling and Avoiding Web Page Errors, Part 3: An Ounce of Prevention”（英文）

原則 8：測試性能、可伸縮性和可靠性

瀏覽器并不是準確的測試方式，它只能向您展示應(yīng)用程序可能的用途。請針對您的應(yīng)用程序設(shè)置特定的性能目標，并使用 Web Application Stress Tool 等負載工具進行壓力測試。您需要自己決定您的環(huán)境所能接受的條件，以下是一些幫助您啟動測試過程的通用指導方針：

• 通過測試 ASP 每秒鐘的請求數(shù)對性能進行測試，并建立一個最小的閾值。一般情況下，不執(zhí)行數(shù)據(jù)庫訪問的簡單 ASP 頁每秒鐘至少應(yīng)返回 30 頁。調(diào)用組件或訪問數(shù)據(jù)庫的頁每秒鐘至少返回 25 頁。
• 向應(yīng)用程序不停地追加用戶，直到每秒鐘的請求數(shù)低于預先設(shè)置的閾值，用這種方式測試可伸縮性。
• 從 Web 集群中移去機器，并檢查錯誤和故障情況，以便測試可靠性。

將測試環(huán)境與實際運行的環(huán)境相匹配，甚至防火墻也不例外。這聽起來代價很高，但我曾經(jīng)聽說過開發(fā)人員因為沒有考慮到防火墻，而丟失了工作。

有關(guān)使用 Web Application Stress Tool 測試 ASP 應(yīng)用程序的詳細信息，請參閱“I Can't Stress It Enough -- Load Test Your ASP Application”（英文）。

原則 9：增加隔離性

使用隔離功能保護您的應(yīng)用程序過程能夠極大地增強服務(wù)器的穩(wěn)定性。談到 Internet 應(yīng)用程序，是否使用隔離功能的后果可能會有巨大的差別：一個是應(yīng)用程序崩潰，一個是服務(wù)器當機。保護主 IIS 進程 (InetInfo.exe) 通常會排在優(yōu)先級列表的較高位置。在您使用組件時，這一點尤為突出。

通常所采用的保護主 ISS 進程的技術(shù)是使 Web 應(yīng)用程序運行在各自的內(nèi)存空間中。在 Internet Services Manager 中，您可以針對每一個 Web 設(shè)置這一選項。雖然因?qū)M程進行編組而開銷的系統(tǒng)資源會對性能有些微的影響，但對應(yīng)用程序所起的保護作用值得付出這一代價。 在 IIS 4.0 下，您可以采用進程內(nèi) (in-process) 和進程外（out-of-process，OOP）兩種方式運行應(yīng)用程序。OOP 應(yīng)用程序會運行在新的 Mtx.exe 實例中。在 IIS 5.0 下，您還能使用其他的隔離選項?？梢詫⒏綦x級別設(shè)置為“低”（對 Inetinfo.exe 來說是進程內(nèi)應(yīng)用程序）、“中”（DllHost.exe 共享實例）或“高”（Dllhost.exe的非共享實例）。

除了將 Web 應(yīng)用程序隔離在它們自己的內(nèi)存空間中之外，您可能還希望隔離不信任的組件。不信任的組件通常是在實際環(huán)境中沒有通過測試時間的考驗的組件。您可以在 Server 包中運行這些組件，這樣它們會運行在新的 Dllhost.exe 實例中。

一般而言，如果要在性能和保護措施之間采取中庸之道，方式如下：在“高”隔離狀態(tài)運行 Web 應(yīng)用程序，在庫包中運行組件。這種方式最大限度地減少了編組開支，同時在進程之間提供了最強的保護作用。

詳細信息，請參閱文章“Server Reliability Through Process Isolation”（英文）。

原則 10：不要濫用線程共用組

在 IIS 4.0 下，針對每個受 MTS 管理的處理器，ASP 的默認共用組是 10 個線程。在 IIS 5.0 中，默認值是 20。這就意味著每一線程都是一份潛在的寶貴資源，能夠處理多個客戶機請求。您同樣需要避免調(diào)用會出現(xiàn)阻塞的方法，如進行大的數(shù)據(jù)庫調(diào)用。如果您有要執(zhí)行這種操作的工作，它將阻止 ASP 應(yīng)用程序?qū)㈨憫?yīng)快速返回到客戶機，則請考慮使用隊列功能。例如，在 NT 4.0 中，可以使用 MSMQ。在 Windows 2000 中，可以使用 Queued Components（排隊組件）。

在會話中不要存儲 Single-threaded Apartment (STA) 組件，這種方式的一個共同缺陷是會填滿會話范圍中的 Visual Basic 對象。會將用戶鎖定到某一線程，與線程共用組的目的背道而馳。潛在的用戶會被阻塞在其他用戶的后面，等待創(chuàng)建他們組件的線程變得有效。您應(yīng)該采用別的方式，設(shè)計能基于每一頁進行創(chuàng)建和破壞的無狀態(tài)組件。

快速提示：確保已在服務(wù)器上禁用了 ASP Script Debugging 功能（使用 Internet Services Manager）。如果啟用了 ASP Script Debugging，則 ASP 的執(zhí)行過程將被鎖定到某一線程。

詳細信息，請參閱以下文章：

• “Q243544 INFO: Component Threading Model Summary Under Active Server Page”（英文）
• “Q191979 PRB: VB Component Not Marked Apartment Produces ASP 0115 Error”（英文）
• “Q243548 INFO: Design Guidelines for VB Components Under ASP”（英文）
• “Q243543 INFO: Do Not Store STA Objects in Session or Application”（英文）
• “Tuning Internet Information Server Performance”（英文）

摘要

創(chuàng)建 ASP 應(yīng)用程序需要相當寬廣的知識面。ASP 應(yīng)用程序所面臨的一個挑戰(zhàn)是目前沒有通用的規(guī)則（這也正是樂趣的一部分）。另外一個問題是許多開發(fā)人員接觸 Internet 開發(fā)之前是從事桌面系統(tǒng)的開發(fā)工作。通過在您的 ASP 開發(fā)工作中應(yīng)用上述規(guī)則，您有希望避免犯下代價巨大的錯誤，并能開發(fā)出相當不錯的 ASP 應(yīng)用程序。

J.D. Meier 出生并成長于美國東海岸。聽從 Horace Greeley 的建議，他成為一名開發(fā)人員支持工程師，主要致力于包括 MTS 和 ASP 技術(shù)在內(nèi)的服務(wù)器端組件以及 Windows DNA 應(yīng)用程序。