雖然許多使用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 會話或者應用程序變量中。