bababa
Groupie
加入: 2004/5月/29
Online Status: Offline
回復: 46
|
| Posted: 2004/5月/29 3:52下午 | IP記錄
|
|
|
作者：J.D. Meier
Microsoft Corporation
2000 年 1 月 24 日
如果您符合以下幾種情況，這篇文章正適合您：
從 Active Server Pages (ASP) 程式碼調用元件
設計將從 ASP 程式碼調用的元件
希望利用 ASP 程式碼中的元件
目錄
簡介
為什麼使用元件？
狀態管理
範圍
分割服務
線程模型
安全性
Server.CreateObject 與 CreateObject
傳遞參數
事件
OnStartPage/OnEndPage 與 ObjectContext
錯誤處理
全局變量
分佈元件
結論
簡介
元件。有人喜歡它們，有人則害怕。害怕元件的人通常都能給您講一個駭人的經歷。讓我們面對它：當開始在 ASP 下使用元件時，並不知道什麼能傷害您。如果您摔倒了，那麼站起來，自己拍乾淨，然後接著來。在這篇文章中，我將提供從實踐中獲得 的一般指南，幫助您建立更好的基於元件的 ASP 解決方案。
為什麼使用元件？
在我開始討論元件指南之前，值得考慮將元件增加到 ASP 應用程式的價值。許多對元件不熟悉的開發人員總覺得一切都那麼新鮮。元件可以為 ASP 應用程式帶來以下種種益處：
封裝功能和隱藏實現細節
可重用性（包括被不同客戶機應用程式重複使用）
知識產權保護
可伸縮性（體現在允許將應用程式分佈到多台電腦上）
配置和部署靈活性
性能（尤其在早期綁定是重要因素時）
訪問系統，例如 Win32 API 調用或編程語言的任何其他底層功能
鍵入功能較強（「Visual Basic® 指令碼編輯器 [VBScript]」的鍵入功能較弱，而且 JScript® 也不太好）
業務邏輯與使用者界面分離，或者 Web 設計人員與 Web 開發人員分離
利益與付出同在。就增加開發過程的複雜性而論，創建元件解決方案可能更加昂貴。部署和疑難解答也可能變得更困難並成為現實因素。 但是，不要讓眼前的困難阻礙了長期的利益。如何知道付出的成本是否值得呢？請考慮下列方面：
現有的程式碼庫是如何？
開發隊伍的水平和經驗怎樣？
您對主服務器的控制範圍如何？
為特定任務選擇了什麼樣的工具和語言？
存在什麼協同問題？
存在性能和可伸縮性的因素嗎？
項目時間框架是什麼？
誰會繼續維護和支持該應用程式？例如，開發小組能介入和接管嗎？
審查以上考慮的問題後，請考察您的假設。原型能迅速從設想中得出實際情況。
現在，對元件可能帶來的益處有了一定的理解，讓我們繼續討論。下面的指南將幫助您獲得最大的益處。這些指南可能成為指引您順利建 立更穩定的、可升級的、性能更優的 ASP 元件應用程式的嚮導。
狀態管理
建議
一般來說，在可能的場合盡量使用無狀態的元件和無狀態的 ASP 網頁。元件不應需要狀態從一個方法調用到下一個狀態。將複雜的狀態儲存在資料庫中。對於簡單的資料、沿用 cookies、QueryString 或在網頁之間傳遞資料的隱藏的表單字段。
為什麼
服務器資源是有限的。維護元件中的狀態意味著應用程式在資源衝突和並發問題時將消耗寶貴的資源。無狀態元件將幫助您避免這些問題 。無狀態元件還提供更多的部署選項，並增強在多個客戶機上共享資源的能力。
常見的陷阱
開發人員常犯的錯誤是設計或使用需要維護狀態的元件。請注意防止這種常用於桌面開發的思想。通常，具有桌面開發背景的開發人員會 設計出依賴狀態的元件。
詳細訊息
避免使用「ASP 會話」將提高服務器的性能，因為它簡化了程式碼路徑並減少了服務器資源的消耗。如果不使用「ASP 會話」，請通過「Internet 服務管理器」 （請參閱「Internet 訊息服務 [IIS]」文檔）禁用「會話」狀態。也可以在不需要「會話」的 ASP 網頁中使用下面的標記禁用基於頁的「會話」：
<%@ENABLESESSIONSTATE=False %>
部署靈活性是另一個重要方面，尤其在 Web 區域中執行應用程式時。如果依賴「ASP 會話」, 則給定使用者的請求綁定在指定的 Web 服務器上，因為「會話」狀態是服務器專用的。在中間層和 Web 服務器中避免狀態，並使用資料庫，將使 ASP 請求可由區域中任何有效的 Web 服務器處理。因此, 您將減少競爭，提供更好的冗余，並允許更多的分佈選項。
不使用「ASP 會話」而在頁間傳遞資料的其他方法，請參閱下面的「知識庫 (KB)」文章：
Q175167 HOWTO: Persisting Values Without Sessions（英文）
Q157906 HOWTO: Maintain State Across Pages with VBScript（英文）
Don Box 在 ActiveX® Q&A（英文） 一文中 還提出有關 MTS 狀態管理的更多見解。
範圍
建議
通常，請在網頁範圍內使用元件。網頁範圍的含義就是在同一頁上創建對像、並使用它和釋放它 — 所有這些均在同一頁上操作。
標記為「雙重」或「單元」的元件在網頁範圍內都能正常工作。僅在網頁範圍內使用「單元」模型元件，例如 VisualBasic 元件。如果需要在「應用程式」或「會話」中儲存元件，則建議使用「雙重」。可以在「會話」或「應用程式」範圍內儲存標記為「雙重 」的元件，但元件需要保證線程安全。
為什麼
在網頁範圍內使用元件使服務器資源得以回收。釋放資源將使並發問題減到最小程度，並允許可彙集的資源在客戶機上共享。另外，網頁 範圍元件避免了影響「會話」 或「應用程式」範圍的對象的線程問題。在下面的「線程模型分類」中將詳細討論線程問題。
常見的陷阱
最常見的問題之一就是在「應用程式」範圍內儲存 Visual Basic 或其他「單元」模型對象。如果您嘗試在「應用程式」範圍內儲存一個用 Server.CreateObject 創建的「單元」模型對象，可以看見下面的錯誤：
應用程式對像錯誤 'ASP 0197: 80004005'
不允許的對象使用
/VirDir/global.asa, line 7
不能將帶有單元模型行為的對象增加到應用程式的內部對象。
但是，如果使用 <OBJECT> 標記在「應用程式」範圍內儲存「單元」模型對象，就不會出現執行錯誤。相反，對像將創建在指定的「單線程單元 (STA)」線程上，並且所有調用都彙集到那個線程 — 而且是連續地。原因是沒有復選該元件的線程模型。很遺憾，在執行時出現了問題。
另一個常見問題是在「會話」範圍儲存「單元」模型對象，該「會話」範圍將使用者會話綁定到指定的線程。這個行為嚴重影響服務器的 性能。由於所有調用將連續地彙集到創建該對象的線程，因此從根本上影響了線程緩衝池的目的。
詳細訊息
有關詳細內容，請參閱下面的 KB 文章：
Q243543 INFO: Do Not Store STA Objects in Session or Application（英文）
Q243548 INFO: Design Guidelines for VB Components Under ASP（英文）
分割服務
建議
將表達、業務和資料服務分離。業務元件應該實施業務規則。業務元件不應包含資料訪問技術。那是資料層元件的任務。業務元件不應包 含對 ASP 對象的引用。
ASP 提供表達服務。引用 ASP 的對象應該呈現為 HTML。這些對像能夠依次調用對 MTS/COM+ 註冊的業務對象。
為什麼
將應用程式分割為單獨的和截然不同的服務，有以下好處：
更便於元件的重用
支持 Windows DNA model（英文）
更好地孤立疑難問題
更靈活的部署選項（去掉服務的耦合允許在多台電腦上分佈應用程式）
常見的陷阱
有一種我們稱為「瑞士軍刀」元件的常見問題。 該「瑞士軍」元件將所有服務合成一體 （就像有螺絲錐、牙籤等 17 種工具的小瑞士軍刀）。 把不相關的服務組合到一個元件中， 使該元件很難使用、理解和維護。
容易掉入的另一個陷阱是從業務元件中引用 ASP。使 ASP 和業務邏輯耦合（通過使用 請求或響應對象，或在其內部構建 HTML），不僅限制不同的客戶機重用您的元件，而且限制了橫向的可伸縮性。引用 ASP 內置對象的對像應該與 Web 服務器在同一框圍中。理想情況下，由於橫向可伸縮性，業務元件可以分佈在不同的框圍中。可以直接在 ASP 指令碼中提供表達服務，也可以建立呈現引用 ASP 內置對象的元件的 HTML，並將這些元件保持在 IIS 框圍中。
詳細訊息
成功的設計模型可用作處理公共業務問題的模型。例如，處理「創建讀更新刪除(CRUD)」 操作的模型，可幫助您將應用程式分為幾個截然不同的邏輯服務，即表達、業務規則和資料訪問。
請參閱下文以獲得更多的設計模型具體示例，可以在您自己的應用程式中模仿它：
Scalable Design Patterns（英文）
Simplify MTS Apps with a Design Pattern（英文）
FMStocks Application: Start Here（英文）
線程模型
建議
選擇元件的範圍還是選擇元件的線程模型，哪種方法優先？兩種方法都要考慮線程分支，除非決定在網頁範圍內使用「單元」或「雙重」 模型元件。（如果 Visual Basic 程式員不知道元件是哪種線程模型，則總是「單元」。）
如果需要在「應用程式」或「會話」中儲存對象，則需要使用標記為「雙重」的元件並聚集「自由線程編組程式 (FTM)」。
不要使用「單線程」元件並避免使用來自 ASP 的「自由線程」元件。
注意： 如果不小心， Visual Basic 可產生「單線程」元件。請確保在項目屬性頁的常規選項卡上將線程模型設置為單元線程。還要注意在相同選項卡上選定無人值守執行和 保留在內存中選項。
為什麼
如果您使用的是 Visual Basic，它是一種「傻瓜」開發環境。 Visual Basic 僅限於使用「單元」模型。假如 Visual Basic「單元」模型對像執行得非常良好，我不想對網頁範圍上的限制考慮太多。 Fitch 和 Mathers Stock 2000 破壞了對性能的任何預先想法。另外，由 ASP、SQL 和 Visual Basic 構建的許多現有網站，無時不刻都在證明網頁範圍的「單元」模型元件是可伸縮和執行的。
如果在標記為「雙重」的元件上聚集 FTM，則可以不用任何編組或線程切換，便能在線程之間調用。如果標記為「雙重」的元件沒有聚集 FTM，ASP 將其視為「單元」線程對像 — 就像 Visual Basic 元件一樣。請記住，如果計劃利用「COM+ 對像池」，則不要聚集 FTM。 有關「對像池」的規則，請參閱「平台 SDK」文檔。
「單線程」和「自由線程」元件執行在「系統」安全環境下。更糟的是，「單線程」元件會導致死鎖。
常見的陷阱
也許最常見的陷阱就是使用了沒有被設計為在 ASP 下執行的元件，如「單線程」元件。大多數開發人員陷入其中，是因為將桌面應用程式移向 ASP，或者使用了第三方的控件時。如果您不能確定元件的線程模型，可以檢查元件的註冊表項（但不能總依賴它）。
詳細訊息
有關線程模型及其對 ASP 的影響，請參閱下面的文章：
Don Box's Active Server Pages and COM Apartments（英文）
Agility in Server Components
另外，下面的 KB 文章提供了有關線程問題的詳細內容：
Q243543 Single-Threaded Apartment Objects in Session or Application（英文）
Q243544 INFO: Component Threading Model Summary Under Active Server Page（英文）
Q150777 INFO: Descriptions and Workings of OLE Threading Models（英文）
安全性
建議
元件不應對它執行的使用者環境做任何假設。不要訪問使用者專用訊息，如 HKEY_CURRENT_USER，或桌面電腦的專用資源，因為這些對元件來講是不可用的。應用程式也不要使用 SendKeys 或調用依賴使用者界面的元件，執行通常需要桌面交互的操作，如打開對話框。
為什麼
元件將執行在不同安全性的桌面上。首先，這表示應用程式不能打開對話框，並不能與其他 GUI 實用程式交互（例如，使用 SendKeys）。默認情況下，不允許 Inetinfo.exe 與桌面交互。不同的使用者環境也會限制元件訪問某些資源 — 主要是註冊表的 HKEY_CURRENT_USER 部分。
常見的陷阱
常見的失誤是引用 HKEY_CURRENT_USER 下的表項。例如，Visual Basic 的 GetSetting 和 SaveSetting 函數不能在 ASP 下使用，因為它們引用了 HKEY_CURRENT_USER 配置單元下的表項。下面的 KB 將討論這個問題：
Q248348 PRB: SaveSetting and GetSetting Not Available in Visual Basic 6.0 Webclass (IIS Application)（英文）
當從 ASP 而不是從桌面客戶機調用元件時，列印機、MAPI 訊息和網絡共享通常「失效」。
有關詳細內容，請參閱下面的 KB 文章：
Q184291 PRB: COM Objects Fail to Print When Called From ASP（英文）
Q217144 INFO: Difficulties Using Net APIs in ISAPI and ASP COM Objects（英文）
Q207671 HOWTO: Accessing Network Files from IIS Applications（英文）
詳細訊息
有關安全性的幾點考慮：
啟用哪種 IIS 身份驗證方法？
您的 Web 應用程式是進程內的還是進程外的？
如果元件以 MTS 或 COM+ 註冊，它是在「服務器」上還是在庫軟體包中？
您正在調用本地 DLL、遠程 DLL、本地 EXE、遠程 EXE 嗎?
有關安全性的詳細說明超出了本文的範圍。但是，由於這個主題的複雜性，下面的文章對從 ASP 元件角度理解問題有很大幫助：
Securing a Web-based Microsoft Transaction Server Application（英文）
Q172925 INFO: Security Issues with Objects in ASP and ISAPI Extensions（英文）
Q217202 PRB: CGI Applications and IIS OOP Applications May Fail（英文）
下文很好地概述了 IIS 如何處理安全性：
Authentication and Security for Internet Developers（英文）
Server.CreateObject 與 CreateObject
建議
使用 Server.CreateObject。如果正在使用 MTS/COM+ 庫軟體包，請使用 Server.CreateObject 來避免線程阻塞。
為什麼
CreateObject 相當於通過指令碼引擎調用 CoCreateInstance。如果使用 CreateObject 而不是 Server.CreateObject，將發生下面情況：
ASP 不能識別該對象。
OnStartPage/OnEndPage 網頁方法沒有調用。
ASP 不知道對象的線程模型。
Server.CreateObject 相當於 GetObjectContext.CreateInstance。這表示 ASP 清楚該對象並知道它的線程模型。另外，如果 ASP 網頁是事務性的，則通過調用 Server.CreateObject 可使元件與 ASP 網頁在同一事務中。（請注意，事務性的網頁可能意味著可避免的業務規則與表達層的耦合。）
常見的陷阱
如果對像處於防火牆後面，可能需要調用 CreateObject。請參閱 Q193230 PRB: Server.CreateObject Fails when Object is Behind Firewall（英文） 以獲得詳細訊息。
詳細訊息
雖然在 IIS 4.0 下面 CreateObject比 Server.CreateObject 快，但在 IIS 5.0 下性能是相同的。同樣，如果正在使用 MTS/COM+ 庫軟體包/應用程式， Server.CreateObject 可防止線程阻塞。
傳遞參數
建議
聲明 Out 參數為 Variant。在 Visual Basic 術語中，這表示按引用 參數應該為 Variant。按值傳遞的參數（In 參數）不限於 Variant，但必須與 Variant 兼容。
為什麼
指令碼客戶機使用 Variant。 COM 服務器可使用指定的資料類型。當您將指定的資料類型按值傳遞給 COM 服務器時， COM 服務器可以毫無問題地接收。但除 Variant 外，其他按引用參數無法「回送」給 ASP 指令碼。
常見的陷阱
最常見的錯誤之一是「類型不匹配」。這通常是因為按引用 傳遞到 COM 對象的變量不是 Variant。通常的解決方法是按值傳遞參數或者將參數變為 Variant。
詳細訊息
如果要在多台電腦上分佈元件或在進程外執行它們，可能看到按值 傳遞參數獲得的顯著性能。按引用傳遞將在進程或電腦間造成更多的編組開銷，因為資料必須往復發送。如果實際上並不需要按引用傳遞 參數時， 按值傳遞參數的正確性和有效性也是一個問題。注意，在默認情況下 Visual Basic 按引用傳遞參數。
下面的 KB 文章討論將參數從 ASP 傳遞到 COM 對像：
Q197956 PRB: Passing Parameters By Reference to a VB COM Object（英文）
Q197957 PRB: Passing Parameters By Reference to a VC COM Object（英文）
事件
建議
避免調用等待其他元件返回事件的元件。
元件方法應盡快返回對 ASP 的執行。請考慮使用「MSMQ」或「COM+ 排隊元件」 來提供異步調用 — 或當要做的工作正長時間執行並且不必聯機執行時。
請異步地分派工作項目，而不要讓 ASP 等待長時間執行的進程結束。然後您將從 ASP 給客戶機返回一個響應。一旦工作項目完成，您可以用電子郵件或其他方法通知客戶機（請參閱下面內容）。
為什麼
ASP 並不是為處理事件設計的。為了優化服務器性能，請盡快返回對 HTTP 請求的響應。
常見的陷阱
循環檢查服務器上的狀態標識並不是一種提供瀏覽器通知的「服務器友好」方法。
詳細訊息
通常開發人員關注事件的原因是為了給瀏覽器提供關於在服務器上處理的工作的通知。雖然可以開發出精緻的瀏覽器通知系統，如通過套 接字在服務器上打開另一個端口，但許多開發人員通過下面的技術實現他們的需要：
使用電子郵件通知
在網頁中增加 Meta-Refresh 標記以輪詢服務器。
發送到瀏覽器的連接，並讓客戶機手動檢查未決請求的狀態。
下面的 KB 文章討論這些問題：
Q243547 PRB: ASP Does Not Provide Progress Notifications to Client Browsers（英文）
Q243546 PRB: ASP Does Not Support Events（英文）
OnStartPage/OnEndPage 與 ObjectContext
建議
在 IIS 4.0 及更高版本中使用 ObjectContext 訪問 ASP 內置對像（如響應、請求、服務器等等）。無論何時請盡量避免使用 ScriptingContext 對像、 OnStartPage 和 OnEndPage。
為什麼
OnStartPage、OnEndPage 和 ScriptingContext 對象是用於遺留支持的。
常見的陷阱
如果插入 ASP 對象，ATL 嚮導將使用 OnStartPage 和 OnEndPage。
詳細訊息
用「雙重」或「單元」模型元件獲取 ObjectContext 而無須以 MTS/COM+ 進行註冊。對於本地的 ActiveX EXE 不能使用 ObjectContext，所以需要使用 OnStartPage/OnEndPage。若要使用「自由線程」和「單線程」元件環境，需要以 MTS/COM+ 註冊這些元件。否則需要使用 OnStartPage。
錯誤處理
建議
錯誤處理器將期待著意外情況。捕獲應用程式每一部分中的錯誤，並盡可能完整地記錄下來。好的日誌對於跟蹤、隔離和疑難解答有重大 意義。這些日誌可以實現為文本文件或寫入 NT 事件日誌。在多數情況下，邊增加訊息邊「冒出」錯誤，是通知調用者已經出錯的有效途徑。冒出錯誤使調用者可自由地與處理具體問題 的具體方法交互。
當記錄錯誤時，提供盡可能多的有用訊息至關重要。考慮包括以下幾點：
目前使用者環境（調用 Win32 API — GetUserName）
目前線程 ID（調用 Win32 API — GetCurrentThreadId 或 Visual Basic 中的 App.ThreadId）
目前時間（使用 Win32 GetTickCount，得到的是毫秒資料）
傳遞至方法的參數
錯誤源，包括方法名
為什麼
根據我們的經驗，好的錯誤處理和記錄是隔離和診斷執行時問題的最有效途徑。
常見的陷阱
還記得 ASP 0115 錯誤嗎？ 但願您不用和它苦苦鬥爭了。 如果還在為其苦惱， 建議您參閱 Troubleshooting with the IIS Exception Monitor（英文）。
ASP 0115 錯誤不是總出現在開發人員的控制下 — 但多數時候是這樣，錯誤處理可能已經避免了很多這種情況的發生，還可能在其發生時幫助解決了它們。
總之，最大的問題為跳過錯誤處理或沒有包含有用的診斷訊息。
在 COM 中，罕有跨越元件的界限傳播異常的情況。捕獲異常 — 但返回 HResults，以向調用者傳送失敗訊息。
詳細訊息
下面的文章提供了有關有效錯誤處理的應用示例：
Fitch & Mather Stocks: Web Application Design（英文）
全局變量
建議
避免在元件中使用全局變量。在 Visual Basic 術語中，這表示在標準的 .BAS 模塊中沒有 Public 或 Global 變量。
為什麼
Global 變量並不是真正意義上的全局。每個線程都有自己的副本。如果幾種方法恰好在同一線程中執行，它們將看到相同的變量；否則它們訪問 的是這些變量的不同副本。這意味著您可能給一個全局變量賦了值（在線程 A 中），但其另一個使用者（在線程 B 中執行）看不到新值。
其原因是 Visual Basic 內部使用「線程本地儲存 (TLS)」來引用全局變量。這意味著每個線程都有自己的 Public 變量的副本，並且因為它存在多個副本，全局資料並不是真正「全局的」。也就是說，恰好在同一線程中執行的使用者才會訪問到同一個 變量，不論他們是否期望如此。
常見的陷阱
如果在標準 .BAS 模塊中使用 Public 變量，當不同線程向還想使用同一個資料的不同使用者請求提供服務時，這個資料可能已被破壞了。
詳細訊息
Visual Basic Programmer's Journal（英文）1999 年 6 月版中由 Matt Curland 所著的下列文章 是必讀的：
Black Belt Programming - Create Worker Threads in DLLs
COMponent Builder - Create Efficient Multithreaded Apps
另外，下面 Daniel Appleman 所著的文章 很好地概述了 Visual Basic 中多線程的工作原理： A Thread to Visual Basic（英文）
分佈元件
建議
元件的分佈涉及性能、可伸縮性和安全性問題。相同元件的不同分佈可能產生更高性能、更易伸縮和更易管理的配置。
下面的指南有助於提高在多台電腦上分佈元件時的性能和可伸縮性：
在 IIS 的同一框圍中執行引用 ASP 內置對象的元件。
在應用程式服務器上執行資料庫元件。
在哪一台電腦上執行業務元件很重要。倘若您去掉業務元件與任何 ASP 的耦合，您就可以根據您的應用程式設計、電腦的可用性和測試，來自由選擇。
當然還有例外。但這些是指南的好的開始。
為什麼
跨電腦分佈元件使應用程式可以滿足伸縮性要求。其次，上面提到的指南有助於實現應用程式的性能和可伸縮性目標。
對像引用 ASP 內置對象，會與您的 Web 服務器進行大量通訊，並且由於它們是表達層的一部分，因此它們就在那裡。
資料庫或對資料極為敏感的邏輯可能在資料庫的儲存過程中。將資料訪問元件置於應用程式服務器而非資料庫上，避免了元件之間的昂貴 調用。相反，資料訪問元件則利用 SQL Server 通信（如 TCP/IP）與資料庫更有效地通信。
常見的陷阱
您應當嘗試避免下列問題：
當橫向可伸縮性較為合適之後，繼續追求從您的電腦開始的縱向可伸縮性。
忽視了防火牆的考慮（幫自己一個忙。如果電腦間的產品環境有防火牆，則在測試方案中增加防火牆。）
將引用 ASP 內置對象的元件置於與 IIS 服務器分離的電腦上（回調和編組 ASP 內置對象的成本很高。）
使用元件內部的後期綁定（這產生對 GetIdsOfNames 的額外調用，這在分佈式應用程式中可能很昂貴。盡量使用早期綁定。）
按引用傳遞參數（這產生更多的編組開銷。盡可能「按值」傳遞參數。）
成功地從 IIS 調用遠程 MTS 元件也可能很棘手。一個簡單有效、既提高性能又簡化安全性問題的解決方案，是調用中間的 MTS/COM+ 軟體包/應用程式。早期綁定可減少網絡路程段，提高性能。如果您使用「服務器」軟體包/應用程式，則可以設置軟體包/應用程式的 執行標識。這個技術將在 KB 文章 159311 Instantiating Remote Components in Microsoft Transaction Server and Internet Information Server 中討論。
詳細訊息
如果已經解耦了服務，特別是已使 ASP 在業務元件之外，則分佈將相當靈活。您就可以更多地考慮框圍，並根據需要分散元件以解決隨之而來的可伸縮性和性能問題。如何知道 ？進行測試。如何測試？請看下面的基本指南：
若要測試 Web 網站的可靠性，請剖析電腦並檢查錯誤。
若要測試性能，請查看每秒可處理多少 ASP 請求。
若要測試可伸縮性，請設置每秒需要處理多少 ASP 請求的閥值。用重要的工具考驗應用程式——增加使用者直到性能壞到不能接受為止。
加強對應用程式的測試非常重要，因為需要暴露運轉條件和單瀏覽器測試中不會出現的其他問題。
有關對應用程式加強測試的詳細內容， 請參閱 I Can't Stress It Enough -- Load Test Your ASP Application（英文）。
結論
正如所見，有一些事情在整個開發中需要時刻注意。在此，應用程式指南所涉及的諸多因素已全部闡明，因為它們有助於徹底避免嚴重失 誤。在整個開發週期中遵循本文中略述的幾個指南，不僅可以避免一些額外的工作，而且能夠提交可收縮的、可靠的、高性能的基於 ASP 元件的解決方案。
|
標題 
名單 
搜索 
Help
注冊 
登入
DoReMe : ASP教學區
話題: ASP 元件指南
