透视和调整你的企业和商务系统（Ⅱ：COM+、ASP） （ccBoy原创）

和调整你的企业和商务系统（Ⅱ：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支持的单一数据类型的情况,现实的应用中可能会是：