Component Object Model

COM:The Component Object Model 组件对象模型

COM组件是遵循COM规范编写、以Win32动态链接库（DLL）或 可执行文件（EXE）形式发布的可执行 二进制代码，能够满足对组件架构的所有需求。遵循COM的规范标准，组件与应用、组件与组件之间可以互操作，极其方便地建立可伸缩的应用系统。COM是一种技术标准，其商业品牌则称为ActiveX。

近几年来，组件在 软件开发中得到了广泛的应用，尤其是WindowsDNA将组件应用于Internet，进行各种事务处理，显示出了强大的功能。从组件机制和接口标准方面探讨组件不是一件轻松的事情，我们这里仅从工程应用的范畴讨论组件的开发与使用问题。

组件在应用开发方面具有以下特点：

----第一， 组件是与开发工具语言无关的。开发人员可以根据特定情况选择特定语言工具实现组件的开发。对于Internet应用而言，完成事务逻辑处理计算任务的组件以MSVisualBasic进行开发是首选方案。其结果是开发迅速，调试方便，编译之后的组件以二进制的形式发布，可跨Windows平台使用，而且 源程序代码不会外泄，有效地保证了组件开发者的版权。

----第二， 通过接口有效保证了组件的复用性。一个组件具有若干个接口，每个接口代表组件的某个属性或方法。其他组件或应用程序可以设置或调用这些属性和方法来进行特定的逻辑处理。组件和应用程序的连接是通过其接口实现的。负责集成的开发人员无需了解组件功能是如何实现的，只需简单地创建组件对象并与其接口建立连接。在保证接口一致性的前提之下，可以调换组件、更新版本，也可以把组件安插在不同的应用系统中。

----第三， 组件运行效率高、便于使用和管理。因为组件是 二进制代码，运行效率比ASP 脚本高很多。核心的商务逻辑计算任务必须由组件来担纲，ASP 脚本只起组装的角色。而且组件在网络上的位置可被透明分配，组件和使用它的程序能在同一进程中、不同进程中或不同机器上运行。组件之间是相互独立的，MTS使对组件的管理更加简便。组件对象通过一个内部引用计数器来管理它自己的生存期，这个计数器存放任何时候连接到该对象的客户数。当 引用计数变为0时，对象可以把自己从内存中释放掉。这使程序员不必考虑与提供可共享资源有关的问题。

对于使用组件的集成开发者而言，一个组件就是一个接口集，只有通过接口才能与组件进行通信；而对于组件来说，接口是包含一个函数 指针数组的内存结构，每个数组元素的内容是一个由组件所实现的函数地址。在一个应用程序中，起决定作用的是组件的接口而不是组件本身。只要组件的接口保持不变，组件可以任意升级或更换，而应用程序不必做任何修改。接口将特定的行为封装起来，一方面使客户可以用同样的方式处理不同组件，一方面同一组件可以在不同的应用中使用。这些特点决定了组件必然有很好的重用性。

COM其实是微软的一套模块（各种exe和dll)交互的标准。

     目前windows上有三套模块交互的标准。第一套，dll，第二套COM，第三套.NET。众所周知，win32是通过dll的导出表这种方式暴露的一整套非oop的函数，这是第一套的典型代表。第二套的代表

是DirectX等等。

    要体会COM的目的，就必须从dll的不方便之处说起。第一，dll暴露的是纯函数，没有面向对象，当然，用c++做dll，类也是可以导出的，但这又牵涉到第二点。这个第二点就是，你如果导出一个指

针类型，vb等这些没有指针的语言该怎么处理呢？所以就需要一套独立于所有语言的，数据交互格式。第三，导出的函数是线程安全吗？也就是两个线程可以同时访问吗？是可以再进入的吗？

(reenterable)等等。这些问题dll的简单的导出表是无法回答的，只能自己在两个模块的编程人员上协商好。既然如此，在模块需要大量交互的情况下，编程人员还要做很多附加的工作，微软索性就重新

修订了一套模块交互标准，把如上的这些因素都考虑进去，这就是COM的初衷。

    在COM里，一个接口可以看成一个dll的导出表，一个COM对象不再像dll那样，只能有一张导出表了，COM对象可以有N个接口，每个接口可以导出一大溜函数。当然，COM必须规定这些接口的标

准，而且是在二进制上（汇编级的），也就是在内存上的每个接口是什么样子的（大概就是c++的虚函数表的样子），因为COM要跨语言。两个语言如果对接口的内存模型不一致，一个call过去，结果

call错了东西，不是函数，程序就崩溃了。同时，COM还要规定接口里可用的各种数据格式。最后，COM提出了一个套间（apartment）的概念，套间说白了就是一种协调缓冲机制，在这种机制下，不

管对方是单线程访问你，还是多线程，COM通过处理，最终都能转成不会让你崩溃的方式来访问你的代码，你的代码就达到了线程透明。

    线程透明，大概的过程如此，当多个线程同时访问你代码的时候，COM的套间的实现代码就像小蜜一样，会叫他们一个个排队，这样，最终到你代码里的，其实已经是单线程的调用了，所以，你的

代码不会崩溃。COM的这种“小蜜”技术，既然可以实现线程透明，显然还可以推广，于是进程透明，网络透明都可以做到了，中间步骤交给“小蜜”处理就好了。

在第二套模块交互标准建立之后，微软大部分的API就不单用dll函数的方式暴露了，更多是用COM来暴露，比如DirectX，浏览器的二次开发等等。

    由上可知，如果你的程序交互简单，大可不必用COM，用个dll导出表，足矣。如果程序导出的功能较多叫复杂，还是用COM这种方式暴露出接口为好，这样比较清晰。很多人说COM死了。我觉得

看你怎么看，如果说COM功能会被移除，这几乎是不可能的，因为只是一套标准而已，而且还有诸多基于COM的程序。但微软基本上不会用COM的这套标准来暴露API了，这可能是事实。