ASP 應用程式開發原則指南

簡介

　　“Active Server Page (ASP)”應用程式的成功常常取決於對體繫結構和設計這兩方面的取捨。考慮到 ASP 技術的範圍之廣和當前應用程式固有的複雜性，這種取捨是非常困難的。本文中，我將為您提供一些特定的指導方針，以助您成功開發基於 ASP 的應用程式。

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

　　原則 1：採用標準方法

　　建立命名規範並使目錄結構標準化，可以協助您大大提高 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_ 建立於 Global.asa。

　　m_ 對於 ASP 頁或在 Include 檔案中是局部的。

　　（沒有首碼） 非靜態變數，對於過程來說首碼是局部的

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

　　儘可能採用目錄結構為您的各個應用程式組件提供始終如一的位置。您應用程式的實際目錄結構當然由您自己決定，但通常是將映像、文檔、include 檔案和組件分別放置在單獨的目錄中。以下是簡單 ASP 應用程式目錄結構樣本。

　　目錄結構樣本：

　　\SimpleAspApp

　　\Docs

　　\Images

　　\Includes

　　一個好的目錄結構允許您有選擇地應用 NTFS 許可權。您還可以從 ASP 應用程式內部使用相對路徑。例如，可以使用以下代碼，從位於 SimpleAspApp 目錄的 default.asp 頁，引用 Includes 目錄中的 include 檔案 top.asp：

　　./includes/top.asp

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

　　有關結構化 ASP 應用程式的其他一些提示和技巧，請參閱文章“ASP Conventions”（英文）。

　　原則 2：設計為在服務下運行

　　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”（英文）

　　“Q172925 INFO: Security Issues with Objects in ASP and ISAPI Extensions”（英文）

　　原則 3：封裝商務邏輯

　　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 指令碼直接將業務組件自動化。

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

　　常見的問題是，從案頭系統到伺服器的過渡。許多具有案頭系統背景的開發人員從來沒有為伺服器的一些問題和資源共用擔心過。在傳統的傳統型應用程式中，串連到伺服器是個耗時的過程。為了改善使用者的體驗，通常採用儘早擷取資源和延遲釋放資源的方法。例如，許多應用程式會在它的整個已耗用時間內始終串連著資料庫。

　　這種方式在傳統的傳統型應用程式中能夠正常工作，其原因是使用者數量非常明確，容易加以控制，並且後端與前端緊密串連。然而，對於當前的 Web 應用程式，這種方式已經不可行了，其原因是有限的伺服器資源將面對越來越多的使用者。為了使您的應用程式能夠應付使用者的增加，您需要盡晚擷取資源，儘早釋放資源。

　　共用有助於增加這一方式的有效性。通過共用，多個使用者能夠共用資源，而且等待時間最少，對伺服器的影響也最小。例如，在處理資料庫時，ODBC 串連共用和 OLEDB 資源共用可以實現從共用池中選擇串連，最大程度地減少串連資料庫的開銷。

　　有關共用 ADO 的詳細資料，請參閱“Pooling in Microsoft Data Access Components”（英文）。

　　原則 5：使用資料庫維護複雜的狀態

　　儘管 HTTP 協議是無狀態的，ASP 開發人員還是會經常使用 ASP 功能內建的狀態保持機制。例如，使用 ASP 技術內建的 Application 對象，開發人員所儲存的資源能夠為應用程式的所有使用者共用。通過使用 ASP 內建的 Session 對象，開發人員只為單個使用者儲存資源。

　　儘管聽起來在 ASP 技術的 Session 對象中儲存資訊是一個非常方便的保持狀態的方式，然而這一方式付出的代價太大，而且它也可能成為對延展性的最大的限制因素之一。應用程式的延展性本質上是隨著使用者數目的增長能夠繼續保持其效能的能力。而對於每一使用者，在會話逾時或被放棄之前，Session 對象都會消耗伺服器的資源。會話還會將您捆綁到一台伺服器上，從而限制您利用 Web 叢集的功能。請儘可能不要使用 ASP Session 對象進行狀態管理。如果您完全沒有使用會話，您就可以禁用 Web 應用程式的 Session 狀態（請參閱 IIS 文檔）。否則，您可以使用下述語句，針對每一頁禁用 Session 狀態：

　　<%@ENABLESESSIONSTATE=False %>

　　對於一些簡單的資料，您可以使用 QueryString cookie 或隱藏的表單域保持 ASP 請求間的狀態。然後，對於更為複雜的資訊，通常推薦您使用資料庫。一般所採用的方式是產生某一特有的標識符，然後發送到每一個發出請求的客戶機，並儲存為隱藏的表單域。在隨後的請求中，這一特有的標識符被用於在資料庫中尋找與該使用者相關的狀態資訊。這一方式提供了更高的延展性和更為簡潔明了的代碼。

　　有關使用 QueryString cookie 和隱藏的表單域的詳細資料，請參閱“Q175167 HOWTO: Persisting Values Without Sessions”（英文）。

　　原則 6：使用 Server.CreateObject 建立對象

　　在建立 ASP 技術的對象時，您可以選擇 <OBJECT> 標記、Server.CreateObject 和 CreateObject 三種方式。每項技術的行為略有不同。儘管在 IIS 4.0 中，使用 <OBJECT> 標記或 CreateObject 比 Server.CreateObject 略具效能優勢，我們一般還是推薦使用 Server.CreateObject， 以便於 ASP 應用程式認知您的對象。（注意在 IIS 5.0 中，前兩項與 Server.CreateObject 相比，已經沒有效能優勢。

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

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

　　原則 7：提供豐富的疑難解答資訊

　　確保在您所有的 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 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：測試效能、延展性和可靠性

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

　　通過測試 ASP 每秒鐘的請求數對效能進行測試，並建立一個最小的閾值。一般情況下，不執行資料庫訪問的簡單 ASP 頁每秒鐘至少應返回 30 頁。調用組件或訪問資料庫的頁每秒鐘至少返回 25 頁。

　　嚮應用程式不停地追加使用者，直到每秒鐘的請求數低於預先設定的閾值，用這種方式測試延展性。

　　從 Web 叢集中移去機器，並檢查錯誤和故障情況，以便測試可靠性。

　　將測試環境與實際啟動並執行環境相匹配，甚至防火牆也不例外。這聽起來代價很高，但我曾經聽說過開發人員因為沒有考慮到防火牆，而丟失了工作。

　　有關使用 Web Application Stress Tool 測試 ASP 應用程式的詳細資料，請參閱“I Can't Stress It Enough -- Load Test Your ASP Application”（英文）。

　　原則 9：增加隔離性

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

　　通常所採用的保護主 ISS 進程的技術是使 Web 應用程式運行在各自的記憶體空間中。在 Internet Services Manager 中，您可以針對每一個 Web 設定這一選項。雖然因對進程進行編組而開銷的系統資源會對效能有些微的影響，但對應用程式所起的保護作用值得付出這一代價。 在 IIS 4.0 下，您可以採用進程內 (in-process) 和進程外（out-of-process，OOP）兩種方式運行應用程式。OOP 應用程式會運行在新的 Mtx.exe 執行個體中。在 IIS 5.0 下，您還能使用其他的隔離選項。可以將隔離等級設定為“低”（對 Inetinfo.exe 來說是進程內應用程式）、“中”（DllHost.exe 共用執行個體）或“高”（Dllhost.exe的非共用執行個體）。

　　除了將 Web 應用程式隔離在它們自己的記憶體空間中之外，您可能還希望隔離不信任的組件。不信任的組件通常是在實際環境中沒有通過測試時間的考驗的組件。您可以在 Server 包中運行這些組件，這樣它們會運行在新的 Dllhost.exe 執行個體中。

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

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

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

　　在 IIS 4.0 下，針對每個受 MTS 管理的處理器，ASP 的預設共用組是 10 個線程。在 IIS 5.0 中，預設值是 20。這就意味著每一線程都是一份潛在的寶貴資源，能夠處理多個客戶機請求。您同樣需要避免調用會出現阻塞的方法，如進行大的資料庫調用。如果您有要執行這種操作的工作，它將阻止 ASP 應用程式將響應快速返回到客戶機，則請考慮使用隊列功能。例如，在 NT 4.0 中，可以使用 MSMQ。在 Windows 2000 中，可以使用 Q 。在 Windows 2000 中，可以使用 Queued Components（排隊組件）。

　　在會話中不要儲存 Single-threaded Apartment (STA) 組件，這種方式的一個共同缺陷是會填滿會話範圍中的 Visual Basic 對象。會將使用者鎖定到某一線程，與線程共用組的目的背道而馳。潛在的使用者會被阻塞在其他使用者的後面，等待建立他們組件的線程變得有效。您應該採用別的方式，設計能基於每一頁進行建立和破壞的無狀態組件