和調整你的企業和商務系統（Ⅱ：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支持的單一數據類型的情況,現實的應用中可能會是：
