（二）。
寫入方物理體系結構
SQL Server XML 模板經過高度流程化，能盡可能高效地通過 HTTP 訪問數據庫。為此付出的代價是功能集受到限制。在模板中找不到所需功能的情況下，SQL Server 的專用 ISAPI 應用被替換為 ASP、ASP 和 COM+ 的組合或自定義的 ISAPI 應用。
本節中說明的體系結構適用於您的頁面要執行下列操作的情況：
訪問多個服務器上的數據庫
處理在設計時未知其格式的 HTTP 請求
調用 COM/COM+ 對象
使用 COM+ 事務
連接至 Internet 上的任何應用或 Web 服務，例如付款提供程序
圖 4：寫入方體系結構
Web 層上的代碼表示應用功能的四個層——數據訪問、業務邏輯、工作流和表示。在開發應用時，請確保此代碼與體系結構保持一致。這可使代碼的可讀性更高，也更易於維護。如果決定單獨使用 ASP，腳本類的效率會更高。如果在業務邏輯層或工作流層有大量復雜的處理，對這些層使用 COM+ 組件可能速度更快。相反，對於處理量相對較小的情況，使用腳本可能速度更快。
這種新體系結構更出色的原因是，所有層（從數據到表示）都使用 XML 來傳輸和存儲信息。數據庫中的存儲過程使用這些新功能來讀寫 XML。數據訪問層利用 ADO 2.6 流與數據庫進行高效、基於 XML 的通訊。
更新穎的方法是將某些中間層下移到數據庫中。
以數據庫為中心的體系結構
Duwamish Online 體系結構基於這樣一種設想：因為數據庫的可伸縮性最低，它應該設計成執行盡可能少的任務。分布式分區視圖等新功能允許在多個服務器之間分擔工作量，從而提高了數據庫的可伸縮性，使開發人員可以選擇將大部分工作放在何處。
如果選擇將“腳重”服務器群集（數據庫方面功能更強）與 SQL Server XML 體系結構一起使用，則另一種方法是使用與 n-層組件的分層方式相似的方式來對數據庫中的存儲過程進行分層。要實現這一點，必須有好的編程方法，例如選擇適當的數據結構和盡可能避免重復代碼。
圖 5：以數據庫為中心的體系結構
這種體系結構中的表示層還包含用於訪問數據庫中的存儲過程的代碼。此代碼可能與傳統數據訪問層中的代碼相同。但是，調用此代碼時數據訪問層可能會出錯，因為這些例程調用工作流層提供的接口。
在使用存儲過程進行開發工作時應該小心避免出現缺陷。讓我們先來看一個設計，這個設計使用了幾個智能存儲過程，它們先執行該層的公共任務，然後再執行在下一個層上繼續執行其代碼路徑的邏輯切換。在工作流層中調用“智能過程”將對應於若干個不同的操作之一。此過程如下所示：
CREATE PROCEDURE
/* 這是一個智能過程，執行工作流操作 */
DoWorkflow
/* Action 用於選擇該調用的多個操作之一 */
@Action nvarchar(255),
/* SomeOtherParameters 是一個占位符，用於工作流所需的其他輸入 */
@SomeOtherParameters ntext
AS
/* 執行工作流的公共操作 */
Execute SomeCommonWorkflowOperations
If @Action = N'Action1'
BEGIN
/* 執行 Action 1 */
Execute BusinessLogicAction1
END
Else If @Action = N'Action2'
BEGIN
/* 執行 Action 2 */
Execute BusinessLogicAction2
END
GO
第一次調用此過程時，SQL Server 優化執行恰好第一次運行的任何代碼路徑。這使其余代碼路徑的運行效率降低，盡管它們的成本可能更高或者使用的頻率更高。
為確保優化執行所有代碼路徑，可為每個操作創建一個單獨的過程，盡可能避免切換邏輯。為防止代碼重復，所有層中多個操作共享的函數應該放在單獨的過程中。當該設計產生大量過程時，優化可以大大提高應用的效率。
集成
Web 開發中最值得稱道的一點是用戶看不到實施過程。因此，本文中介紹的體系結構可以輕松地合並到單個應用中，而無需用戶參與。下面是一些准則，可以幫助您更輕松地集成應用的不同部分：
在整個應用中使用 XML。XML 可以用於任何技術中，可以使用 XSL 樣式表輕松地進行轉換，還可以毫無困難地存儲在任何地方。
文
