所有的优秀程序员都会尽自己的最大努力去使自己所写的程序具有更好的可重用性，因为它可以让你快速地写出更加健壮和可升级性的程序。
有两种使代码重用的选择：
1．白盒：最简单的一种，就是把你的程序片拷贝到另一个文件中。
2．黑盒：它包括把编译过的程序片连接起来。因此客户端可以调用的编译过的黑盒类库就叫作组件。
.Net中也同样为开发者提供了类似于COM的建立和展开组件的方法。开发人员很轻易地被这两种以组件为基础的开发模型所迷惑，所以，让我们来看一看这些不同的开发方法，以使我们消除迷惑。
COM的产生
在以前程序设计过程中，程序员把它们的函数库放在一个叫做目标(Object)文件的单独文件中，在这些文件中，包含了编译过的代码。当程序员要使用一个非凡的目标文件的时候，他们把客户程序编译成机器代码，然后依靠动态链接的手段把客户程序联接到目标文件上，最后变成一个单一的可执行文件。这种作法的唯一的好处在于它节省了编译函数库的时间。但是它有许多的缺点，比如由于在每个单独的可执行文件中都有一个程序库包括在里面，浪费了许多存储空间；对应用程序的维护也是非常困难的，假如在函数库中发现了一个bug，整个可执行文件都要被重新编译和分发。
还有不只一个的严重的限制在里头，一个客户应用程序必须要和用同一种语言编制的函数库在一起才能使用。比如说，一个用QuickBasic写的客户应用程序就不能引用一个用C++写的函数库。
因此，微软公司出品了COM，COM仅仅只是一个规范。不管组件用什么语言写成，只要符合这个COM规范，就能被用任何一种语言写成的客户程序调用。此外，程序员不必再担心要去建立一个单一的可执行文件，因为组件是以GUID（Global Unique Identifier全球唯一标识符）来标识的。GUID是一个128位的号码，和一些相关的信息一起被放在系统的注册表中，用来唯一标识组件。客户应用程序只在运行期间才动态地建立一个组件的实例，并使用这个组件的功能，因此，只需要一个函数库的拷贝。它的缺点就是大家经常提到?quot;DLL地狱"。这个问题在一个DLL要被一个新版本的DLL所取代时引发。开发者不得不通过关闭所有的客户应用程序的方法（假如不行，还要关闭WWW服务）来达到清除所用对这个组件的引用的目的。有时所有的方法都还起不了作用，那你只好重新启动服务器后才能替换掉老的DLL。
COM+
为了让企业级的应用程序能使用上COM，它必需要有以下的特定的能力。
· 验证能力
· 对象池（Object Pooling）
· 事务处理
· 支持分布式架构
为了使开发者不必去为他们的组件添加这些能力，微软公司出品了DCOM（Distributed COM分布式COM）和MTS（Microsoft Transaction Server微软事务服务器）。使用这两种技术，开发者就可以把精力用在他们的商业逻辑上，而不必放在后台的他们的组件上。
DCOM是一个用于分布式的组件之间的通讯的RPC（Remote Procedure Call）协议。客户端向一个本地机的代理类发送请求，然后由代理类将这个请求隐含地给安装在远程机器上的"根"类，然后执行结果原路送回给代理类，最后代理类把它们回送给客户端。因此，客户程序的位置完全与组件的位置无关。DCOM的缺点在于，由于DCOM使用的是一个独立的硬件端口，而不是HTTP协议的80端口，所以在组件间通讯的过程中，必须保证这个端口是开着的。这是一个严重的安全问题。所以DCOM不能够轻易地穿越防火墙。
为了使用MTS，程序员在它们的组件里放置非凡的MTS钩子，编译后把他们放在MTS包中。把有关系的组件放在一个单一的包中有它自己的好处。当客户请求一个包中的一个组件的一个实例的时候，MTS确保为这个包建立一个新的专门的线程，一个新的组件实例被建立在这个线程上并被应用事务服务。至于对象池服务和安全服务是否要被建立，那就要看开发者的请求了。
MTS答应相关的作业单元被当作一个事务来对待，这意味着假如所有的作业单元被成功地完成，整个事务就被当作成功地完成，反之假如有一个单元未成功完成，整个事务将被重新轮回。
在客户请求对象和释放对象后，MTS仍保存着这个对象，所以当另一个客户请求同一个组件的时候，MTS就将保存着的对象交给它。通过这种方式，MTS减少了在服务器源实例化的次数。
MTS答应开发者用安全措施来组装他们的组件，以使其具有识别请求它的服务的客户的能力。这能够确保未经授权的客户不能够使用组件的功能。
MTS以COM+的名义被完整地整合到了微软公司的windows 2000操作系统中，但是COM+不仅仅只有MTS，它还包括一些其它的服务。MSMQ（Microsoft Message Queue Server），一个与MTS一同发布的服务，也被以COM+的名义整合到了Windows 2000中。MSMQ答应服务器端和客户端进行同步的通讯。事件服务（Event Service）也被加了进来，它使服务器能够与客户端同步地交流事件的发生。负载平衡服务（Load Balancing）自动地实例化机器上的具有最多资源的服务器上的请求对象。
.NET
.Net提供了一种全新的建立和展开组件的方法。它就是大名鼎鼎的Assemblies。使用COM，开发者必需要在服务器上注册组件，这也就是说，系统注册表中的组件的信息必须被更新。这样做的目的是保证组件的中心位置，以使COM+能够找到合适的组件。使用.Net的Assemblies，装配（Assembly）文件把所有需要的元数据（meta data）都压入一个叫Manifests（名单）的一个非凡的段中。在.Net中，要使assembly对用户有效，只要简单地把他们放在一个目录中就行了。当客户程序请求一个非凡的组件的实例的时候，.Net运行期（runtime）在同一个目录搜寻assembly，在找到后，分析其中的manifest，以取得这个组件所提供的类的信息。由于组件的信息是放在manifest里的，所以开发者就没有必要把组件注册到服务器上，因此，就可以答应几个相同的组件安全地共存在一个相同的机器上了。
建立一个.Net assembly并不像建立一个VB6组件，唯一让开发者操心的就是商业逻辑，所有的后台代码全部由.Net运行期产生，而且由于.NET运行期具有碎片收集器的功能，组件不必担心它的引用数目（在COM中是靠Iunknown的帮助）。简单地说，在.NET中建立一个assembly比建立一个VB6 COM要简单地多。
纯的.NET assemblies不能够在COM+服务下注册，因为它们是和COM不同的二进制标准。面对.NET，assemblies的前景相对于COM来说是"高级的COM"。但是由于当前架构于COM+上的应用程序的可靠性，COM还会持续一段时间。这也许就是微软公司向开发者同时提供开发.NET assemblies和COM的工具的原因吧。
类型库引入器(Type Library Importer (TLBIMP.exe))工具可以把COM组件封装成.NET，以使以前的东西可以在.NET应用程序中继续使用。
类型库导出器（Type Library EXPorter (TLBEXP.exe)）工具将.NET组件封装成COM，这个工具也是很有用的，假如你要用你的.NET assemblies去替换原有的COM组件，就得用到它了。由COM+提供的服务不能被忽略，所以把.NET assemblies封装成COM组件就变得相当重要了。作为一种选择，开发者可以从.NET基础类库中选择更多的功能。进入讨论组讨论。
