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_ | 創建於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”（英文）。
ASP 將在服務下運行。設計ASP 應用程序時，您馬上會面臨在桌面應用程序中不會遇到的安全環境和線程問題。在桌面環境中，通常只處理作為交互式用戶運行的單線程執行，而且有權訪問當前的桌面系統。在“Internet 信息服務(IIS)”中，模擬不同用戶環境的多個客戶機線程調用您的應用程序，而且您的應用程序被限於“系統”桌面。
這對您來說意味著什麼？請學習IIS 的安全模式。還要提醒您：僅因為某些東西能在Visual Basic IDE 下能夠正常運行，並不意味著它就能在ASP 技術中安全運行。 Visual Basic IDE 並沒有準確地模擬運行時環境。常見的設計錯誤包括：在ASP 技術中使用需要用戶界面的.OCX 控件，使用對線程來說不安全的組件，和使用要求特殊的用戶上下文的組件。要避免的一個最簡單的問題，就是從應用程序中試圖訪問HKEY_CURRENT_USER (HKCU) 註冊表項（例如，不要調用Visual Basic 的GetSetting和SaveSetting函數，它們都依賴於HKCU）。同樣，不要出現需要用戶進行人機交互的消息框或其他對話框。
以下文章是有關ASP 技術中的安全和驗證問題的相當不錯的入門讀物：
ASP 技術通過生成HTML 輸出提供了表示服務。簡而言之，它會生成用戶界面。您需要將商務邏輯從ASP 表示腳本中分隔開來。即使您不使用COM 組件將商務邏輯從ASP 代碼中分隔開來，至少也要將商務邏輯分隔到函數和include 文件中，以提高可維護性、可讀性和可重用性。在需要排除故障和隔離問題時，您還能體會模塊化設計方法的好處。
調用腳本內部調用函數和方法，可避免代碼亂作一團，並能在ASP 應用程序中添加結構。下面舉例說明從ASP 代碼中，將邏輯分離到方法調用中：
lt;% Main() MyBizMethod() ... Sub Main() GetData() DisplayData() End Sub%>
在使用包含ASP 功能的技術時，可以應用這一原則。下面舉一個使用Visual Basic WebClass 時的例子，說明如何使用這一原則：
常見的問題是，從桌面系統到服務器的過渡。許多具有桌面系統背景的開發人員從來沒有為服務器的一些問題和資源共享擔心過。在傳統的桌面應用程序中，連接到服務器是個耗時的過程。為了改善用戶的體驗，通常採用儘早獲取資源和推遲釋放資源的方法。例如，許多應用程序會在它的整個運行時間內始終連接著數據庫。
這種方式在傳統的桌面應用程序中能夠正常工作其原因是用戶數量非常明確，容易加以控制，並且後端與前端緊密連接。然而，對於當前的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 和隱藏的窗體域的詳細信息，請參閱“Q175167 HOWTO: Persisting Values Without Sessions”（英文）。
在創建ASP 技術的對象時，您可以選擇
以下是一個可能出現的例外情況：當您通過防火牆進行調用時，您可能需要調用CreateObject而不是Server.CreateObject 。詳細信息，請參閱“Q193230 - PRB: Server.CreateObject Fails when Object is Behind Firewall”（英文）。
確保在您所有的ASP 應用程序中都包含了錯誤處理過程。而且，確保您提供了有用的診斷信息。我還沒有碰到有哪個人抱怨錯誤信息太具有說明性了。請確保在錯誤日誌中包含以下信息：
因為將在ASP 下運行，您可能希望將這些信息寫到文件或NT 的事件日誌。您還可以創建記錄關鍵的應用程序事件的應用程序事件日誌，以備診斷應用程序錯誤時使用。
以下文章提供了有關錯誤處理技術的詳細信息：
瀏覽器並不是準確的測試方式，它只能向您展示應用程序可能的用途。請針對您的應用程序設置特定的性能目標，並使用Web Application Stress Tool 等負載工具進行壓力測試。您需要自己決定您的環境所能接受的條件，以下是一些幫助您啟動測試過程的通用指導方針：
將測試環境與實際運行的環境相匹配，甚至防火牆也不例外。這聽起來代價很高，但我曾經聽說過開發人員因為沒有考慮到防火牆，而丟失了工作。
有關使用Web Application Stress Tool 測試ASP 應用程序的詳細信息，請參閱“I Can't Stress It Enough -- Load Test Your ASP Application”（英文）。
使用隔離功能保護您的應用程序過程能夠極大地增強服務器的穩定性。談到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”（英文）。
在IIS 4.0 下，針對每個受MTS 管理的處理器，ASP 的默認共用組是10 個線程。在IIS 5.0 中，默認值是20。這就意味著每一線程都是一份潛在的寶貴資源，能夠處理多個客戶機請求。您同樣需要避免調用會出現阻塞的方法，如進行大的數據庫調用。如果您有要執行這種操作的工作，它將阻止ASP 應用程序將響應快速返回到客戶機，則請考慮使用隊列功能。例如，在NT 4.0 中，可以使用MSMQ。在Windows 2000 中，可以使用Queued Components（排隊組件）。
在會話中不要存儲Single-threaded Apartment (STA) 組件，這種方式的一個共同缺陷是會填滿會話範圍中的Visual Basic 對象。會將用戶鎖定到某一線程，與線程共用組的目的背道而馳。潛在的用戶會被阻塞在其他用戶的後面，等待創建他們組件的線程變得有效。您應該採用別的方式，設計能基於每一頁進行創建和破壞的無狀態組件。
快速提示：確保已在服務器上禁用了ASP Script Debugging 功能（使用Internet Services Manager）。如果啟用了ASP Script Debugging，則ASP 的執行過程將被鎖定到某一線程。
詳細信息，請參閱以下文章：
創建ASP 應用程序需要相當寬廣的知識面。 ASP 應用程序所面臨的一個挑戰是目前沒有通用的規則（這也正是樂趣的一部分）。另外一個問題是許多開發人員接觸Internet 開發之前是從事桌面系統的開發工作。通過在您的ASP 開發工作中應用上述規則，您有希望避免犯下代價巨大的錯誤，並能開發出相當不錯的ASP 應用程序。
JD Meier出生並成長於美國東海岸。聽從Horace Greeley 的建議，他成為一名開發人員支持工程師，主要致力於包括MTS 和ASP 技術在內的服務器端組件以及Windows DNA 應用程序。
通過錯新技術頻道小編介紹的內容，相信大家都有了一定的了解，想要了解更多的技術內容，請繼續關注錯新技術頻道吧！