当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）”之中。
－完－
