当COM遇见.NET
荣耀 2002
技术进步是无法遏止的趋势，新老交替更是自然规律。随着新技术的来临，老技术即便不完全退出历史舞台，也将失去曾经拥有的主导地位。作为Windows平台上主流组件技术COM，面对.NET，命运也是如此。
对于不同的开发人员来说，COM意味的东西也不一样。有些人因为领域所限，很少进行COM开发，而大多数开发人员和COM打了那么多的交道，一下子从COM转移到.NET，并不会是多么快速和自然。在新老技术转换过程中，阻力往往并不是来自于技术本身，而是技术的使用者。
C语言诞生之际，遭到来自ASM（汇编语言）程序员的重重阻力，但随着C编译器质量的改善，计算机硬件的飞速发展，C语言易用的优点就逐渐凸显出来，结果，C程序员队伍不断壮大。尽管在某些低阶程序设计领域，仍然活跃着一批ASM程序员，但相对于中、高阶主流语言的用户来说，这个比例是显而易见的小。同样，C++之相对于C、Java之对于C++都有过类似的历史。
今天，在.NET发布的短时间内，开发人员肯定不会立刻放弃Win32 API和COM，也不会将所有代码都移植到.NET上，但在硬件环境和业务需求背景的推动下，在微软的不遗余力的推行下，以及在这个平台自身优点的吸引下，未来几年内，绝大多数Windows开发人员将会把绝大多数精力投入.NET。
COM是一种跨语言操作的二进制标准，语言互操作的魔法通过接口完成，从某种意义上说，COM就是接口。.NET达到了同样的目标，但实现方式不同。.NET提供了通用语言运行时，而后者则实现了通用类型系统。每一种.NET语言都知道如何将自己的对象布局展示给其它语言，同时也知道如何使用和扩展用其它语言编写的对象。
但这并不意味着在.NET中不存在接口。实际上，.NET基类库提供了大量的接口（比如ICloneable）。在CLR中，对象引用既可以基于接口，也可以基于类。现在，你有多种程序设计风格选择，你可以进行传统的基于类的面向对象开发，也可以进行基于接口的设计开发，甚至可以混用两种方式。
COM并不单单是IUnknown和API，除了提供接口外，COM还提供了服务。.NET除了提供接口、对象和CLR外，同样提供了完善友好的服务。.NET克服了COM的缺点，提供并增强了COM的所有优点。可以说，.NET是组件技术的又一个进步，它是比COM更友好的企业模型。因此，假如将COM视作一种编程模型而不是技术细节的话，.NET就更象是对COM的进化，而不是一场取而代之的革命。
你现在应该停止所有COM开发吗？不是。只要你愿意，你仍然可以创建COM组件，.NET提供的COM互操作能力可以保证你在COM上的投资会得到保护。你不但可以从.NET应用中使用COM组件，也可以在COM应用中使用.NET组件。此外，CLR并没有重新实现任何COM+功能，至少在第一版里是这样。你在.NET中使用的COM+服务，和你在pre.NET时代使用的COM+服务，本质上，没什么两样。
即便在.NET时代，某些领域的软件开发仍然会采用COM而不是.NET。尽管.NET的CLR对于很多类型的应用来说都是一个了不起的进步，但对于某些应用（比如系统级软件）来说，它未必是最佳选择，这些软件仍将使用COM技术并采用C++这样的语言进行开发。
在今后几年里，作为一种编程模型，作为一种开发基础设施，作为一种和现存代码互操作的方式，COM仍将被继续使用。但对于使用.NET从头创建的新应用来说，通常不再需要COM。因此，COM虽然仍然重要，但它绝对不会象它曾经那样的重要，COM的应用领域将会不断缩减。越来越多的开发人员，将会跳到.NET这个“沙箱（sandbox）”之中。
－完－
