和調整你的企業和商務系統（Ⅱ：COM+、ASP）
小氣的神 2001-10-11
接著上一篇所說的三個過程中第一個步驟開始進行，環境需要兩部機器，一部做SQL Server，一部做App和安裝IIS。類比現在常見的Windows DNA結構，在ASP中調用Biz組件。VB的Client端我就省略了，選擇IE作為Client端，唯一想驗證的是構架和組件是OK的就好了。
這一篇和dotNET還沒有任何關係，因為那時還沒有dotNET技術，為了更真實的類比現實比如複雜一點帶有事務要求的邏輯，我決定把SQL Server和組件放在兩台機器上。
內容我選用SQL Server內建的Pub資料庫的Author表作為原型。當我翻看原來的一些應用代碼和組件發現整個的代碼一般分為兩類：一類是完成一個商業和商務邏輯的操作，帶入必須的參數給Biz組件，Biz組件調用其它Biz組件或DB組件完成需要的各種操作，然後返回一個簡單的資料類型回來給表現層。比如一個String字串（錯誤描述），一個Long型（表示某種流水號，什麼編號或是錯誤碼等）；另一類是查詢或某種操作之後返回的大量資料，讓我慶幸的是自己已經習慣了用ADODB.Recordset來返回這些大量資料，所以這一類很統一,一般都是ADODB.Recordset類型的傳回值。除此之外連Variant都很少很少，自己定義的結構類型在Biz這一層的傳回值中幾乎為零。
對於WebService來說，資料被統一成XML的格式，我開始想象這些ADODB.Recordset在XML中會是什麼模樣的？用戶端又如何使用這些XML格式的ADO資料呢？幾乎第一個反應是用Microsoft SOAP Toolkit來解決這個問題，所以對SOAP Toolkit產生的WSDL檔案充滿好奇，想知道這種ADODB.Recordset傳回值的WSDL會是怎樣的。事實上，以後實驗的結果讓人泄氣。不過問題更早的暴露出來了，就是這些自訂或說不是SOAP支援的資料類型的資料如何處理的問題，目前集中在ADODB.Recorset這種資料類型上。這些問題也就決定了要產生的db和Biz組件。
DB組件沒有特別的，Biz組件我決定直接調用這些DB組件，先沒有任何的邏輯，事實上Biz中可能是很複雜的，調用很多其它的Biz或DB組件，但往往它最後只會有一個結果：成功或失敗，或是返回一組資料，也就是我上面歸類的兩種。所以我開始用類似的Update,Delete功能：
Public Function DeleteAuthor(ByVal au_id As String) As Long
來類比第一類返回SOAP支援的單一資料類型的情況,現實的應用中可能會是：
