雖然許多使用ASP 的Web 站點根本就不用組件，但在這篇文章中假定ASP 是Internet 客戶機和組件之間的橋樑。
ASP 和組件之間的劃分服務
ASP 最常用於在服務器上創建供客戶機使用的HTML 或XML 文件，因此我們主要討論這種使用方案。這就引出了一個常見的問題，如果ASP 頁面在服務器上，那麼它們是否屬於業務層的一部分呢？在組件世界中，答案通常是否。雖然ASP 確實在服務器上運行，而且可能與應用程序服務器在同一個空間，但是這不能使它成為業務邏輯的一部分。
隨著用戶界面工具的發展或者隨著啟用更多的業務對業務方案，擁有這種明確的區別將獲得巨大的回報。
話說到此，讓我們來看一些最重要的業務層和表示層劃分準則：
令UI 代碼與業務邏輯分離。這包括編寫與UI 耦合的代碼，例如使用ASP 內部組件的MTS 對象，讓它與業務邏輯代碼分離，如同在不同的DLL 中。
將事務與ASP 頁面分離。事務ASP 在某些情況下非常好，但是組件和多層應用程序會改變這種情況。組件不應該依賴由客戶機層來管理它們的事務和業務邏輯語義。
將表示組件（使用請求和響應的組件）與Web 服務器放在相同的機器和/或進程中。如果將使用ASP 內部組件對象的對象放在遠程機器上，那麼對內部組件的所有調用將以回調形式發生。調用IIS 客戶機的是COM+ 服務器，它顯著降低了性能並使安全配置複雜化。可以將這些調整對象放在標記為“庫激活”的COM+ 應用程序中。
ASP 存在於服務器上，因此ASP 頁面必須符合資源共享規則，並且記住可伸縮性。請看下面的詳細內容：
在“會話”中，管理應盡量避免用戶特定的狀態。
保持ASP 無狀態，並在可能的情況下允許資源池。
操作方式
在評價某個代碼段是否屬於業務邏輯或者表示層時，請問一下自己，“如果我必須用按鍵式電話應用程序代替我的ASP 頁面，那麼該代碼是否還有用？”如果答案為“是”，那麼可以嘗試將它劃分為業務邏輯代碼或者用戶界面幫助器代碼。
如果改變了客戶機後該代碼不能用，或者如果它是構造用戶界面的幫助器，則該代碼屬於表示服務層。它在ASP 頁面中，或在使用ASP 內部組件的組件中。它不屬於業務對象組件。
理解桌面與ASP 客戶機的區別
ASP 是組件的特殊客戶機，不同於桌面上的傳統單線程Win32 應用程序。主要區別概括如下。
線程管理：ASP 是多線程客戶機。這意味著可以有許多並發活動一起運行，也許在同一時刻處理不同的ASP 頁面。這說明不能使對象偽稱它是唯一的使用者來獨占系統。這樣做可能有意外的反應，例如，養成一個壞習慣：將對象存儲在ASP 會話或者應用程序變量中。