将现存的信息系统移植到组件化架构

http://www.microsoft.com/china/MSDN/library/archives/technic/develop/explant.asp
 

将现存的信息系统移植到组件化架构

Dave Stearns, Program Manager
Visual Basic讨论组

介绍

逻辑多层架构和实体分布式架构 逻辑多层架构 实体分布式架构	移植的步骤 逻辑化设计 实体设计	下一阶段：组件共享 获得重用的可能性 一般的来源是剪贴 整理一份可用的组件清单 所有权 版本控制 管理计划
顶点：所有组件的开发 组件目录 从属追踪	所有相关的看法

---

简介

一个三层或是多层信息系统架构的好处是，可将其焦点放在一些"信息"的处理工作上，另一方面，对于大部份信息技术专家而言，也是了解和体会此项新技术潜力的良机。然而，信息技术的工作人员在他们大量的信息系统产品中，常常会遗留一些令人感到惋惜的事实，例如：大部份产品里并没有运用"组件"的概念，或在无奈的压力下继续进行系统功能的加强，即使他们知道（这些系统）随着使用年限的延长已经出现了问题也是如此。这篇报告将对该项议题展开讨论，并且将会提供一些实际的建议，而不单单是将现有的系统进行组件化、多层架构化；另一方面也提供了如何以团队开发的概念，将某些信息技术转换到一个"以组件为基础"的新程序开发境界。

逻辑多层架构和实体分布式架构

在开始讨论之前，必须先了解逻辑多层架构和实体分布式架构两者的区别。了解逻辑多层架构和一个实体分布式系统的不同之处，将有助于说明移植现存系统的途径，可持续地进行系统增强，而这则不会产生一个令人生畏的学习过程。

逻辑多层架构

一个逻辑多层架构的设计是应用程序按逻辑工作，它可以分成三个独特的服务领域："用户服务"、"商务服务"和"数据服务"。这种区域分隔方式允许开发人员在数据库和用户程序之间，引入抽象的弹性分层。每一层都负责不同的工作任务，当将它们结合在一起时，会变成一个具有凝聚性、合作性的系统，且具备了弹性、坚固性，及可成长扩充等特性。

"数据服务"主要负责数据的配置和常态性。下面我们以数据库的关联来典型的说明范例，数据服务需要包含所有的储存过程、内含所有组件基本的数据访问，譬如对一个客户的搜索组件等。数据服务所处理的工作较为一般，例如：维护数据的常态性、恢复和保持数据完整一致性等工作，而并不是在数据中实际执行任何一条特定的事务规则。

此外，"商务服务"可以负责建立商务规则。它们在数据服务中"修复和保持数据的完整性"，但它们新增了可实际执行有关应用商务规则的功能。而典型的商务服务范例组件包括：税务计算，它运用了有用的商务数据，如：顾客、产品、订单或授权契约等数据功能，而且还运用了如传真与电话等商务功能。"商务服务"虽然是不可见的，但由于它们可以将商务规则独立出来，因此可以经常地更新商务规则。这些"商务服务"能让用户的工作内容数据具备有效性，或是在做计算和其它应用时，可以充分地运用商务规则。

在信息系统中"用户服务"是可见的。这些服务是将数据显示给用户，并允许用户对这些数据进行操作，并且可以通过商务规则与商务服务链接在一起，进而确认和产生所需的数据。"用户服务"的范例如：窗体、控制、图形及屏幕上所显示的讯息。

上述这些服务的好处是众所周知的，由于不在此篇报告的范围，这里不再赘述﹝要了解关于多层设计优点的更多相关资料，请参阅在Visual Basic 4.0到6.0企业版的文件集，其中记载了有关建立客户端与服务器端的应用范例﹞。在这个可反应商务变化的系统中，以上所述功能足可以带来更多的可维护性、分层性和可成长性。

这些层次基本上是按逻辑区分的，并不表示在实际运作时，那些服务就一定会被分类的位置。其中必须注意的是，观念上可将它们摆在"特定的分层"的设计里，在这里存放着所有可以被执行的服务。也就是说，这种方式允许共享和重复利用所有组件的设计技术，它是系统开发组件化中一项吸引人的优点，此项优点也意味着你将不再需要深入到组件的世界里，即可获得多层设计的好处。

实体分布式架构

当一个系统在逻辑上被分成几层时，它会被组件分化。组件是一个OLE项目，它提供OLE自动化接口的集合，可以使任何OLE自动化的用户应用程序重复使用。这项组件是以二进制的格式进行编译的，加以形态库的包裹，最后以组件来呈现用户接口。组件可以供许多客户端共享，允许重复使用，并且可在任何一种支持OLE自动化服务器的计算机语言中进行开发。

组件以下列以三种方式的产生在客户端上：内部进程服务器、外部进程服务器或是远程服务器。"内部进程服务器"是动态连结﹝DLL﹞，并且在客户端应用程序里使用同一个进程及位置空间。"外部进程服务器"则是在客户端应用程序里，使用不同进程和位置空间。"远程服务器"则是在完全分开的机器上执行，执行时使用其它机器的CPU和系统资源。以上每一种选择均有其优缺点，而且在系统中每一个组件可选择不同的分布式模块。

"内部进程服务器"是在客户端与服务器端之间，理想中高效率的重用组件模式。它们可以快速加载，并且由于占用相同的位置空间，因此在传递给客户端应用程序或是从客户端应用程序传回数据时速度相当快。理所当然地，由于它们同样为客户端的应用程序，并且同属于一个进程空间，因此它们必须位于同一个机器上，然而更新组件却有潜在的困难。在Visual Basic中建立内部进程服务，也必须在相同的线程中执行客户端程序，但如此一来，使它们不能同步执行客户端程序代码。如果在Visual C++中建立内部进程服务，则可产生如背景工作般的多重线程。

"外部进程服务器"是一种组件概念，其需要在分别的进程空间，或是线程中执行客户端的应用程序。虽然这些服务器将会降低加载速度，当在客户端和服务器端之间传输数据时，从一个地址空间传输到另一个地址空间将会造成延迟。但是外部进程自动化服务器仍具有可行性，因为外部进程服务器可以像一个独立的应用程序方便了组件的使用。而且它们是在属于它自己的线程中执行的，那是与客户端应用程序不一样的线程。在这个时候，外部进程服务器可使用定时器来配合背景或可执行异步的工作。

"远程服务器"同样也具可行性，因为它们在与客户端应用程序不同的进程中执行，而且远程服务器也可以在完全不相同的机器上执行客户端应用程序。这是一个非常具有威力的特性，正如它可以让你从客户端机器中，从许多功能强大的服务器上脱线下载，特别是像广域网中的另一个客户端或像慢速连接的Internet。调用或执行"远程服务器"的对象是上述三种方法中最慢的，而且数据传输和函数调用也是三者中最慢的。然而，当在远程机器执行函数调用时，则客户端的CPU将可以释放系统资源，以让其它工作使用。

幸运地，Visual Basic的类模块是完全独立的。但它们会令人混淆，并且会让你浪费时间来学习哪一种实体分散架构最适合现在的系统，通常我们需要一再尝试，并且在内部进程、外部进程及远程服务器之间移动类。有一则好消息，在实体分布式模块间移动类时，客户端程序和服务器端程序无需进行联系。实际上，客户端应用程序不须随时使用，甚至开发人员可在执行时，将组件从外部进程服务器移到远程服务器中，反之亦然。此项配置可独立设置此种状况，其目的是为了更容易将现有系统移植到一个多层架构的设计中。

---

移植的步骤

如上所述，在真实的世界中，信息科技团队持续地推动、维持和加强现存的系统，但是他们也了解到要延长其使用寿命，有赖于将这些系统移植到一个多层架构或是一个以分布式组件为基础的系统中。在下一节中将会讨论一些实际的建议，有关如何将现存系统朝向多层架构发展，却不必将现在的项目完全拆开来等的问题，都有详细讨论。

逻辑化设计

在准备一个三层次架构时，首先要做"逻辑化设计系统"。然而，对那些方法论者也许会感到痛苦又加深了，但是这却是建立以组件基础系统的基本步骤。根据方法论者所提出理论来制作逻辑化设计，也许会很有帮助，但其并不需要一个严格的过程，而且你并不需要对这些过程作太多的服务或考虑。

在逻辑化系统设计阶段，组件的实体和它们最后的配置是有关系的。此项目是确认系统中实际的实体并了解它们之间如何交互。该实体通常是繁重工作的一部分，因为它有处理最近执行工作的能力，并且可以确认哪些事务是相关的。前述技术超出了本篇文章的讨论范围，下一节将提供一些建议，让你了解如何哪些组件是需要先建构的，以及如何花一点时间就可以将你的系统组件化。

请记住逻辑化系统是可增长的，并且要随着系统发展进行更新与改进。它并不像一个项目团队在第一次就要设计出完美的设计，甚至不像当有些情况改变时，仍然保持其完美性。该逻辑化设计必须延续下去且逐渐增长，正如系统一般，在做系统组件化后将会发现移植的发生率更加趋缓。

从何处着手

一旦已确定有多个用户，就应该决定系统中的"商务服务"和"数据服务"中，哪一项是应该首先建立的。然而对许多系统而言，这是个实际问题，当系统完全地变成组件编写时，整个项目不可能随时待命。然而对VB/OLE 服务器技术而言，你可以增加系统组件化程度，可以在项目允许情况下，从中移出一些组件先着手。

第一个步骤是在系统中建立低层组件。由此可知，所谓的这些"低层组件"指的是被整个系统使用的，并且提供了操作系统扩充性的组件。正如你的数据访问组件、登录服务、传送消息和网络服务，还有电话集成服务和状态管理服务等组件一样，这些可重用组件并不限于只在你的项目使用，因为它们可以被整个系统使用，但是大部分系统均有相同的低层要求。当然，对其他项目而言，这些组件的功能，也是极具吸引力的。例如，一个组件允许你的应用程序写入NT的事件日志，而且可能会被其它的应用程序使用。相对地，当你在现存的系统中开始拆开其它组件时，这些组件将需要低层服务，尤其在形成高层组件前，必须要先有低层的组件的存在。

下一步要建立这些服务，它们将对在客户端应用程序中，欲进入一个分开的地址空间，或是一个在实体上不同的机器有所帮助。这些服务的例子包括：信用卡验证，传真程序长时间运算及报表行生成程序。OLE服务器可以在客户端应用程序中的同一个进程，或是在分别的进程，或是在实际上分开的；当CPU中的内部进程服务器执行非常快且容易操作时，它们将会在同一个线程中调用应用程序。外部进程服务器将会以较慢的速率调用应用程序，但是它们可以分别在各自的地址空间和执行序上执行，如：允许后台工作、内存保护等。另外，在远程的例子中，还可将工作分配给两个CPU完成。利用组件化服务，它可以完成长时间运算工作（如报表行生成程序），或在外部进程服务器和远程服务器中，需要特殊的硬件支持（如信用卡验证，传真程序等），如此一来可以提高系统的整体性能，另一方面当后台程序执行或在另外一台机器上执行时，允许应用程序持续进行。像此类复杂的异步处理过程，在长时间计算里将会得到很大的好处。

在启动这两种组件时，一个组件将可以在许多项目的循环周期中，逐渐地将现存信息系统转变成以组件为基础的三层架构系统。将原来的应用程序拆开或是重新编写程序都需要浪费许多成本，但是开发一个组件或是当两个项目循环使用时，均可由系统回收这额外的开销。但如果你尝试将一个现存的系统完全组件化是相当危险的，而且将会导致用户的焦躁而失败，并且可能由于项目团队缺乏经验而导致错误。相对地，若有一个逐渐演化的过程，这个团队会渐渐获得经验，并且适时地将强化部分加入到系统中，这种稳扎稳打的方式才是我们建议的方法。

实体设计

在你已经"确定哪些服务需要建立"时，你的团队必须将重点集中在"组件的实体设计"上。在VB中运用此项基本单位，以类模块建立服务器。每一个类模块为客户端应用程序的新对象定义一个模板（模版），也可以在其它类模块中创建相同的对象。这个类定义了属性与方法的集合，当然每个类在执行时也要维护自己的属性，但是却可以使用类共享的方法实现。

在VB中，类模块是可完全独立放置的，甚至在一个远程的机器上的一个DLL文件或一个 EXE文件，可以如同放在客户端上一样执行。作为一个开发人员，你可以选择将这些类以任何方式分散地存放，不但类模块可以，甚至有些客户端程序为了特定的开发工作，也需要进行修改改变或专门化。

当将一个现存的系统移植到一个三层架构中时，它不但必须将所有的对象组件化（EXE和DLL），当在为自己的多种服务进行类模块开发时，可以将它们放置在主要执行程序或是DLL中，甚至在执行中间先将EXE分开，如果系统需要的话可以再将其放回主要执进程序中。这种可携带性呈现出程序代码与实体配置的独立性，因为这是分布式系统的基本原则。

在下一节中将讨论一些实际的建议，讨论如何在VB中创建类，以及如何将其分布到组件中。每一个系统均有其需要，可以按经验来做，将会为自己的系统在设计类和组件时，考虑各方面的问题。

类和组件的创建

在你的系统中每一个服务都是由一个或多个组件组成。一个对象类是由一组属性和方法定义的，而且这些元素互相结合而定义出接口。该类的接口是非常重要的，并且是类与外界联系通信的契约。设计一个好接口，对类自身而言是一项必备的技巧，而且从某种角度来讲是一种艺术。

设计一个好接口，必须先忘记内部操作，想象你是个用户在 Microsoft应用软件接口中，此种方式称为用户定义，我们所认为用户定义，或向导，将会帮助我们使用那些类来解决问题，或是让用户清楚地知道如何进行操作。通过定义这些用户定义，可以定义一般的要求，而且确定这些例子可以让资的类变得直观且容易使用。如果从用户定义的角度来撰写范例程序，你将会在设计接口中发现各种提示，如：在你的接口里遗失了哪些基本组件，或是着力于需要你定义协助方法可能发生的地方，来使你的操作接口更具亲和性。你必须疆场以用户观点来帮助自己设计用户接口，而并不是以容易设计类考虑。让类集合的使用更自然，或能够轻易使用自己所定义的一般用户接口，这些目标是值得去努力的。

在你的用户接口属性和方法中，有两种要素。在OLE服务器中，属性以小的"方法"来操作（如我们知道的属性Get和属性Let/Set程序），在Visual Basic中，如果声明一项数据成员为公共成员，则VB会为你实际产生类程序范例，一个开发人员在类中声明属性程序与此类似：

Private m_sFirstName As String

Property Get FirstName（） As String
FirstName = m_sFirstName
End Property

Property Let FirstName（sNewValue As String）
If IsValidName（sNewValue） Then
m_sFirstName = sNewValue
Else
Err.Raise vbObjectError + 1, _
"MyServer.Customer", _
sNewValue & " is not a valid name!"
End If
End Property

然后在客户端程序代码中使用属性，如下所示：
Dim cust as New Customer
cust.FirstName = "Dave"
Text1.Text = cust.FirstName

当客户端程序代码给FirstName一个新值，VB 程序代码执行，允许你检查值的有效性或做任何所需动作。此种功能给你最好的两个数据成员，从而直接暴露出客户端程序代码，但是在客户端程序代码，它显示出如果它们和一个类的数据成员一起运作。已允许的程序代码执行时，将会使你已赋值的数据有效化，或直到你需要取出数据时造成延迟。

对于操作只读属性或只写属性而言，属性程序也是非常便利的工具。举例来说，假设你要创建一个顾客对象，你希望在数据库系统里只有一个客户的ID属性，但是将不允许任何一个人更改该属性。根据以下来做，你必须定义一个Get属性过程，但不包括Let属性过程。该程序看起来跟下列程序有点类似：

Private m_nID As Long
Property Get ID（） As Long
ID = m_nID
End Property
'No Property Let routine since this is read-only!

客户端可以参照下列的程序代码：

Dim cust As New Customer
cust.ID = 5

Visual Basic 会自动知道这并不是Let属性过程，或客户端想要编译或执进程序时，它们将会收到一个错误讯息。

因为属性可利用方法来操作，此时自然有个问题出现，那就是什么时候用方法，什么时候用属性？没有一个辛苦且快速的规则，但一般而言，属性是表现现在某个对象的状态信息，但方法则是用来呈现对象的动作。回溯到VBX的时代，开发人员使用各种事件属性，因为VBX控件并没有方法属性，许多VBX开发人员也在其中，这也是一个诱因。这个清楚的例子表示方法较适当，而现在与 OCX及OLE服务器一起，则应该毫无理由操作属性。然而，像背景颜色、前景颜色、版面形式和排列都是一个属性控制的好例子，因为它们表示控件的状态，并且将他们放在控件中使其为不隐含的控制。在OLE服务器中，有一些很好的属性例子：电话号码、用户名称、密码和版本。这每一项均显示出对象的中心概念，其将会保持在两个方法间传递信息，当一个动作在对象里执行时，设定这些属性将不会隐含起来。

为了增加区分属性与方法，开发人员也需要计算在什么状况下可以将参数传入方法，OLE 服务器可对每个方法定义可选择性或是其要求多少参数，可选择参数的项目可以储存几行客户端程序。请参考以下范例：

Dim conn As New Connection
conn.UserName = "Dave"
conn.Password = "LetMeIn"
conn.Server = "SQLServer"
conn.Connect（）

对于用户名称、密码及服务器使用分别的内容，可以产生一个清晰的接口，但它需要更多的程序代码，如此才能达到常见的情况（连接一个数据库）。使用选用参数，相同的程序代码能被分解为：

Dim conn As New Connection
conn.Connect（"SQLServer", "Dave", "LetMeIn"）

该接口能对用户名称、密码及服务器名称定义不同的内容，但客户端开发人员能按参数信息创建连接方法。如果OLE服务器执行连接客户端的外部进程，或甚至可以跨机器执行，第二个程序代码范例将能够更快速地执行，且每一个内容设置会由客户端传送到服务器，这将导致四个双向传输，而不是第二个范例中的一个双向传输。

一旦你在类中创建了内容和方法，它们将可以在Visual Basic对象浏览器中检查。对象浏览器会按照你目前的项目来例出全部的类别，同时任何类将会参照VB的参照对话框。这将使你的服务器几乎是自动归档的，且如果自己的方法和内容不是自明的，则VB允许你每一个类中的每一个内容和方法中定义简短的说明字符串。通过填入这些信息，可以帮助别人使用自己的类别，且这简短的说明字符串将会编译到自己的类以及编译到自己的服务器中，它能让用户使用这些类，而未编入至文件或说明文件中的将有可能遗失或无法安装。

要为你的内容和方法定义说明字符串，启动对象浏览器，然后在链接库／项目对话框中选择自己的项目，并在类别／模块列表框中选择自己的类。

该方法／内容列表框将显示类中所有可用的方法和内容，一旦选择了任何一个项目，该方法的原型或内容，将会与按钮一起显示简短的说明字符串。要定义这些简短说明字符串，可以选择"选项（Options）…"按钮，然后填写叙述表格。除了这简短说明字符串之外，你也可以定义一个说明文件和说明文本ID，如果需要也可以填写其它信息。当单击位于对话框左下角的"？"按钮时，对象浏览器可以使用这信息启动WinHelp。注意对象浏览器为目前项目的类型列出了不同类内容的取得和允许方法，并在方法的最后新增了"[Sub]"或"[Function]"卷标。一旦你使用了OLE服务器EXE或DLL，使用这个类的客户端将可以看到每一笔内容，并且这个方法将不会在末端出现卷标。

一个类的内容窗体有三部分内容，它必须为每个类进行设置。该内容名称可设为任何新名称。这个名称将会被添加到全域名称位置，并且可以使用"Dim x As New <类名称>"。如果要这类显示在目前的EXE或DLL中，该公用内容应只设为 True。如果这个类仅用于组件，则应该将该内容设为 False。该范例内容将以发布选项实行，我们将在下一个段落中对此进行讨论。

组件的发布

在此之前，在Visual Basic类模块是单独放置的，并且你的发布模型服务能够完全地从逻辑和接口设计中分离。而该分配模型也不会因为客户端或服务器源改变而改变，这样在它再度展开后你可以调整对自己的操作系统进行调整，当一个数据库开始生成时将可以进行调整。以下关于争议的叙述可作为当决定分配类型时，对于组件来说，什么是所需要首先建构的最佳选项的考虑。
一旦创建了一个类，它能够提醒客户端项目，或将其移至一个内部进程自动管理服务器（DLL）、一个外部进程自动服务器（EXE）或一个远程自动服务器（位于其它机器上 EXE）。组件的类型将常常支配你所选择的类型和每一个选项的强与弱。

内部进程服务器在执行时是最快的，并且可以自然地象自己的应用程序一样工作。它们小并且可以很方便地激活，且在客户端应用程序同时执行它们时，客户端和服务器间交换数据的速度会非常快和有效。由两种服务集成开发环境开始，第一种类型，一般通常是使用全部应用程序的最底层，对内部进程服务器来说是较好的方式。

在此有两个实例，当需要服务器从客户端执行在另一个运行的线程并且有另一个处理空间，或当服务器也能执行一个独立的应用程序时，在客户端机器有一个外部进程服务器是必要的。如果你的服务不能满足这些需求，它应该内置一个内部进程服务器。但是，对领会一个外部进程服务器新增的好处是非常重要的。当它们激活速度缓慢时，较大的规模和客户端应用程序有较慢的数据交换速度时，它们提供了非同期处理的可能，可以后台或并行地完成工作。服务的交换在数据量中只占较小的一部分，但执行一个冗长的工作不应该在现行的工作中停止客户端的应用程序，对一个外部进程服务器来说才是一个好方法。例如，如果你建立了一个FTP文件传输队列的服务，它将能建立一个外部进程服务器，以在后台由一个Internet上的远程机器复制文件。客户端应用程序能在称为 GetFile的服务器中调用一个方法，传送远程机器的名称、远程文件的名称、在本机机器所使用的文件名称。服务器将由客户端应用程序将其添加到它的队列要求中，并在另一个线程中进行处理，以允许当文件在它们的本机机器中传送时继续工作。

如果选择建立到一个外部进程服务器的服务，并且给客户端上不同实体的机器添加了一项功能，由客户端在一个不同的CPU中执行服务器程序代码，允许最大量地并行处理，并且也许要指定服务器的硬件方式。对VB4而言，远程自动化是一个新的特性，并且OLE自动化也是一个令人兴奋的进展。当它与一个外部进程相比有较复杂的设置时，源程序代码仍会一样精确，并且一个服务器可以在远程至本机中来回移动，而无需重建服务器或客户端。服务对指定的硬件有益，服务较久或复杂的工作将不会因此而陷入困境，客户端机器将是远程服务器的另一个不错的选择。例如，一个在 Excel电子表格窗体中生成大量报表的服务，或一个在传真机端欲向客户发送传真的服务，应该由客户端机器中卸载，工作目录超出了作业队列执行工作所花费的更大量的时间。使用一个远程服务器也能允许你集中对硬件的指定方式，如一个或多个服务器端的传真机或调制解调器，排除了在每一个客户端机器所需的硬件。

当创建了外部进程或远程服务器时，你也能有能力指定每一个类的类型。如果全部特定类实例将在一个处理空间和一个线程中执行，或者如果每一个类的实例应该在它所拥有的线程中的处理空间执行，可以很容易地确定真实的类型。很显然，对于每个选项而言都有减少成本的益处。创建过程和线程需要花费时间，并且将要消耗内存，一旦创建每一个类的实例将和其它实例一起独立地执行，并允许并行地进行处理，尤其时当机器具有多个CPU时更是如此。当运用实例和处理器时，在实体类型上可能有许多变化，可以在Rick Hargrove所著的白皮书远程自动化与Visual Basic 4.0中有计划的分布应用程序中，连接细节叙述。

一旦创建了自动化服务器，就可以在客户端的应用程序上使用它们，当它们是项目中的类文件时，通过在引用对话框中在新的服务器中创建一个引用。引用对话列表会在操作系统的自动化服务器中注册，并且当在VB中创建自己的自动化服务器时，它将自动进行注册。可以使用简易检查框来检查自己的服务器名称是否已经有所有服务器对象的名称位置，及允许你建立对象，如同：

定义客户
Set cust = New Customer

在Visual Basic中声明对象的引用变量是非常重要的。在VB 3.0中，将全部声明为"Object"，但是在VB4.0中，你应该以特定的形式声明这些变量，例如"Customer"。当将"Cust"变量声明该类型"Customer"时，VB将自动读取服务器中的类型程序、语法检查方法，并用所有权在客户端程序代码中调用对象，并直接将其调用到服务器虚拟作用表格中，使实行的方法和所有权访问能达到最快的效果。

---

下一阶段：共享组件

将一个应用程序移植到三层结构，第一阶段是根据组件创建一个企业范围的信息操作系统。建立可以多次使用的组件，它包含了用户、商务和数据服务的目标，如此你可以在整个组织中访问这些组件，在操作系统间重用，这是考虑到商务规则的数据设置。然而，在这个进程的下一步中，将分享一些在不固定项目中的组件。有鉴于移植是一个在技术上十分费力的三层结构的应用程序，共享组件会使得更多的项目管理进行技术上的发布。每一个信息技术组都致力于如何取得组件重用的事件，在这篇文章以下的部分中，将提供一些如何开发组件，以及当开始在项目中重用组件时，要处理哪些争议的实际忠告。

获得重用的可能性

尽管大部份开发人员说重用程序代码和组件是一件好事，但实际上却是一再地重新撰写函数。并且虽然大部份项目管理人员意识到花时间开发可重用组件的会帮助减少未来项目所需的开发时间，但可笑的是往往在最后关头，仍然选择告诉开发人员停止"研发"。唯一取得真正的重用和组件开发的方法是在一个组织的工作能创建一个"重用"的文化。

信息技术组是如此常见的文化，它是一个低调的方法论，若没有50个必需的描述和项目的再检讨便一事无成，或是一团混乱，而由开发人员所产生的程序代码需要再多给予一些关注，才有可能重用。很显然，在重用这种文化的叙述尽头，并不只是需要IT组织去打破这样的平衡，同时也要变更这些项目结构的方法。开发一个可重用的组件就如同开发一个小产品一样，该组件应该经过开发、测试、修正和发布阶段，如果需要的话也应有文档的伴随发布或甚至是本地化。产品的客户是其它重用的应用程序，且就如同大部份产品一样，一旦有新的版本发布，该组件应随时升级。由于这个理由，当其它项目小组在商务解决方案中放置了该组件时，它常常需要去建立项目小组以完全集中在可重用组件的开发上。

一般的来源是剪贴

当重用组件时，从目前看来通过重复使用二进制DLL或EXE，或是通过在项目间剪贴源程序代码一个开发部门便能获得好处。对于重用而言，剪贴看来是似乎可行的方法，并且在一开始，它便能帮助重用文化的建立。但是，久而久之，剪贴程序代码将不会产生一个依赖组件的信息操作系统，例如升级将使组件不会自动继承剪贴资源的应用程序。如果一个开发部门在二进制层次、修正和升级能重复使用组件，这对应用程序会有直接的益处，尽管它对于在应用程序和组件间建立相关性并没有影响。这个相关性将会产生如下所讨论的计划问题，但是如果管理得当，将会使得部门间有更好的合作性。

整理一份可用的组件清单

当你决定共享组件的二进制窗体时，下一步所产生的是什么呢？是另一个开发部门所需要重用的组件。当你在Visual Basic上创建一个自动化服务器时，组件中内置的类型库将包含组件中所有类的清单，以及这些类的所有内容和方法。如果使用对象浏览器给内容和方法添加简短的说明字符串，则以自己的类来浏览，将显示类的一个概要解释，这也是帮助潜在用户的一个办法。这对于大多数用户很有帮助，许多新增的项目都有可重用的组件。

Visual Basic也允许你将说明文件与组件关联起来，并说明每一个类别识别标志（ID）、方法和组件的内容。如果说明文件出现在用户的机器上，他们可以使用对象浏览器打开这些类，并且可以了解更多关于类以及如何使用的细节。许多工具也使得制作说明文件非常的容易，允许组件组提供非常丰富的文件。通常说明文件都是创建为RTF文件，组件组能提供联机说明和由相同文件源所打印的文件。

一个好的可重用的组件应该包含组件简短效述的简单文字文件、一个文件清单、一个可以链接到更多信息的个人或别名，创建这个项目所使用的语言（如果进行了本地化的话）及任何组商业设施组件所需的相关信息。一个组件也许有很长的使用期，其耐久度远超过它的创建者的估计，它必须具备其它的组重用该组件时，联系其他人员获取信息的能力。

请谨记，应将组件作为一个小产品一样看待，且组件应包含在所购买的软件产品中。

所有权

组件概念的所有权是非常关键的，尤其是组件的创建数量和在其他项目的开发中的重用。如果一个开发部门无法访问源程序代码而重用一个二进制组件，他们必须有清楚的所有人，一旦他们遇到bug、问题，或需要加强组件时更是如此。由于这个原因，使得一般项目部门开发组件变得十分困难，甚至使得开发组件的部门在未来也许不会 存在，或在其它项目中进行任何组件的工作都太复杂。建立组件团队能清楚地拥有组件，并将它们作为小产品一样看待，当试图使用组件或遭遇问题时能通过开发部门提供所需的帮助。

若没有清楚的所有权，组件将永远不会在二进制窗体中重复使用，这样开发部门也无法确信一旦他们遇到组件受损时，能取得错误修复，或在未来能有新增的特性。

版本控制

当一个组件团队收到bug报告，或当该团队给该组件添加新特性时，版本控制问题便会出现。利用版本控制，它不会关联到源程序代码版本控制 （当然它仍是重要的），而是关联到组件版本控制，这是一个更困难的问题。一旦你在组件上创建了一个接口，你便无法改变接口的内容或特征，也无法预防应用程序使用旧版的组件。Visual Basic提供了一个特性来帮助你解决这问题，你可以通过在项目选项对话框中设置"Compatible OLE服务器"激活这个特性。开发人员应该将最接近服务器的版本内容设置为文件名称，并完成它。Visual Basic将警告开发人员，如果试图改变类接口，该类将会破坏现存的应用程序。

使用Visual Basic创建的组件将自动地标记上一个分三部分的的版本号码。这个号码可以通过选择"Options（选项）"按钮设置Make EXE 或Make OLE DLL对话框：



第一部份的版本号码是"Major"版本。该部分标志着组件每一个主要更新发行版本的变化。什么构成一个主要的发行版本呢？一个新的主要发行版本应该包含有意义的概念、新组件应与旧版本客户端二进制不兼容，且组件名称的二进制文件也应变化。二进制不兼容意思是旧版本客户端应用程序为了新组件需要重新编译，这意味着在一个或更多类上的一个或更多个方法变化了。在Microsoft在我们的DLL文件中加入表示主要版本号码的后缀，如VBRUN300.DLL。当主要版本变更时，文件名称同时也变更，例如VB40032.DLL。其中，"32"是用来识别一个 32位的DLL是由16位版本变化而来，但当它只为32位时则并不需要。

第二部份的版本是次要版本号码。该次要版本用来指出一个组件细微的功能加强，但不需要对现存的客户端进行重新编译。如果给接口添加了一个新的方法，或做了一系列的错误修正和重新发布，该次要版本号码便会增加。新的组件次要版本应能和旧版客户端二进制兼容，这意味着可以重新发布组件的一个新版本，并可以用它来覆盖现存的版本。然而，许多开发人员也在组件的文件名称中包含了次要版本号码，如同主要版本一样，这样用户可以同时拥有次要版本不同的应用程序。

第三部份的版本号码是修订号码。这个版本的号码在每一个创建的组件中是增加的，并且每一个修订的组件 （只要是主要版本并未变更） 应能与其它版本二进制兼容。这意味组件版本1. 0 1 应能被组件版本1. 0 2取代，且无需重新编译客户端的应用程序。在选定"Compatible OLE服务器"时，Visual Basic将确保该组件二进制兼容，并且当你试图破坏它时将会发出警告。如果选择破坏二进制兼容，应该更新主要版本号码，并改变组件文件名称。要自动增加校订号码，可以在每一次选择创建EXE或DLL时，选取对话框中的"Auto Increment"复选框即可。

管理计划

一旦你开始共享组件，计划的问题将会很快产生。当一个开发团队依靠其它团队的组件开发时，客户端项目计划变会依附在组件计划上，如此当然会引起风险。由于这个缘故，组件项目管理人员永远不能低估这个问题，他们在一定时间内能交付多少组件是非常重要的。承诺太多将导致客户端应用程序计划的延迟，并且会导致出现许多其它依附在组件计划的分裂。

有越来越多的组件被创建为可重用的，组件间的从属关系和应用程序也变得越来越大。每一个计划的管理者则具有非常中央和核心的角色，并且不应被低估。这是另一个为什么团队和项目管理员应该专注一个可靠的组件团队的范例，并且有些必须扮演协调每一个客户端计划中每一个组件的角色。

当一个客户端项目不可能在计划时间内完成某个组件来实现某种程度的工作，或超出组件的角色或领域时，工作计划在此时便很重要。在这些状况下，除了使每一方面的工作都能执行以外，组件的功能必须和客户端相配合进行清楚定位，并且在这些情况下，客户端开发部门也许需要去做一些额外的工作，甚至可能是包含了在稍后要再回到组件制作的工作之中。

---

顶点：所有组件的开发

一个重用组件文化将要建立了，一旦实现，组织便能进入所有组件的开发阶段，新的功能需要将一个可重用的组件放入到应用程序中，并可以与其他项目共享。一个应有的认识，像这样在焦点上的转移并不会一直发生，它可能要花上数年的时间来创建组件，以及在组织的主流重用的观念。

如果团队试图在这个方向成长，将会有些争议如的大规模组件开发的产生。我们将在下面的部分对此进行简短的讨论。

目录组件

在任何组织中人们总是来来去去，因此，丧失了有关可重用组件的知识。如果一个组织可以试着去鼓励组件重用，他们必须是这些组件目录的集中点，允许开发人员寻找适合他们所需的组件，这样就可以使得开发人员无需写一个和现存组件相同的新文件。

组件管理应用程序，包括Visual Basic企业版，提供了一个目录组件问题的解决方案。组件管理员对一个组件数据库（不论是本机还是在SQL Server共享）进行维护，并允许一个管理器将不同类的组件进行分类。开发人员可以使用组件管理器筛选能力快速地确定他们所感兴趣的组件，并在他们的计算机上选择安装这些组件。



组件管理器允许开发人员查看特殊组件中的所有类和事件，每个方法和内容。使用组件管理器，开发人员也可以看到清单或组件的关联文件。当开发人员选择了安装组件时，这些文件也将同组件一起被复制到开发人员的机器上，所有说明文件、Word文档，概要图表或任何种类的文件都能自动地和组件一起安装到每一台客户端计算机上。

在这数百个可能的组件中，搜索、分类和筛选是非常重要的能力。通过组件管理器，一个管理人员可以定义在每个库中的各个类的种类，并且可以将库中每一中类的组件交互联系起来。例如，BookSaleServer组件可以与 "Basic Concepts"和"Data Access"数值相关联，该数值位于"Sample Type"类中，如同"Jet/DAO"位于"Technology"类中一样。一旦建立了这些关联，开发人员便能使用类来筛选他们所要寻找的组件。开发人员也可以通过在"Next Search"表单中输入，进行组织式的搜索。

从属追踪

除了对这些组件进行分类之外，同时也需要去追踪组件。当共享一些组件时，组件部门应持续追踪它们的客户端，以知道有哪些从属是现存的。然而，当组件生产和重用增长后，以及当项目使用中央目录搜索可用组件增加时，在组件间手动追踪从属关系的能力变得几乎不可能了。当一个组件添加了特性时，它需要知道什么应用程序与它有所关联，这样便可以逆行测试这些新组件，并将这些组件发布给它们的使用者。

一般而言，这些组织将使用兼容的操作系统，这样便能很好地持续追踪这些组件的从属关系。Visual Basic在当前还未提供任何工具来存取这些此时关系，但是有许多第三方提供了兼容的解决方案，许多组织也可以编写自己的解决方案。在许多情况下，可以使用某些工具来追踪组件间的从属关系。

---

所有相关的看法

在这份文件中，我们已经讨论了将现存的操作系统升级为一个逻辑上三层结构技术的观点，以及在非技术方面实行企业范围的开发。当产生技术争议以及时常需要学习和实验时，他们通常可以进行轻松的处理和实现。非技术争议并不容易克服，并且通常困惑组织了一个组织向基于组件的开发的转移。

良匠制造好的软件。如同Visual Basic技术，OLE自动化和Windows都是功能强大的工具。一个好的工匠有钉枪在手，将比使用一把铁锤有更高的效率。但用的时间超过两年，它也可能成为招致危险的毁灭性工具。同样，这些技术也可以有助于理解组件开发技术仅仅是方程式的一小部份。

要成为一个组件开发人员，你必须假设自己好象是一个仆人，来领悟开发团队，并且了解自己的客户正在渴望获得你的组件。要使组件开发成功，组件研发部门必须对他们的客户有所响应，满足他们的所需。开发组件并不意味着退却到象牙塔里，去找寻所谓大多数"正确"的解决方案来回答手头的问题，而是迫使在你的客户中有一个设计巧妙的解决方案。只要是软件销售商倾听并对客户有所响应，加入客户所要求的特性，即使这个特性会瓦解这个产品，组件开发人员仍需去创建这样的组件以应付实际所需，使其明朗化并向客户端的应用程序提供所需的特性。如果没有这样的态度，组件的开发将不会生存，并且开发团队创建非共享的组件仍然无法与创建可重用组件的好处相匹敌。