.NET框架与COM：背景和历史，关系的发展

       

      最近在学习COM技术的东西，这项技术似乎很古老了，1993年微软提成来的，到2002年微软大力发展.net技术，对于COM技术似乎提及的比较少。也有人认为.net技术会最终取代COM技术，不过也有人认为COM有其自身的优势，不会被取代。

关于COM的书籍，市面上的确很少，只是在2000年左右出了四五本所谓的经典教材。2002年之后就几乎没有人写相关的书籍了。可能是因为COM技术对于普通的开发人员使用的不多，也可能是这项技术已经没有什么可研究的了。但是对于一个基于windows平台开发的人员，我觉得还是应该学习一下COM技术。不管它是不是真的会被淘汰。就像有了C语言了，汇编在某些时候还是很重要的，虽然普通开发人员使用的少。

　   

       .NET框架与COM：背景和历史

　　可复用软件不是一个新概念。八年来，人们一直在使用各种形式的组件对象模型(COM)。事实证明，它是最为成功的可复用软件模型。COM引进了“组件”的概念——它是可复用的代码块，可以将多个独立函数的功能进行组合，从而扩充成诸如Microsoft Word这样的应用程序。

　　大多数开发人员使用OLE时深刻体验了COM功能。OLE是基于COM形成的一组功能，使得用户能将一种文档嵌入到另一种文档中。这个功能本身似乎不太引人入胜，但它的作用却不同凡响：当用户将一个Excel文档粘贴到Word文档中后，单击嵌入的Excel文档时，OLE将会把Word的工具栏和菜单转换成Excel的工具栏和菜单。

　　从开发人员的角度看，COM通过引进几个明确定义的接口(诸如iUnknown)便可提供代码复用功能，开发期工具可通过这些接口来查询一个组件的功能，并能把这些功能添加到工具中。这就像Visual Basic?开发系统工具箱中的控件能够被拖到某个窗体中一样。实际上，每个控件都代表上百行甚至上千行的代码，可以容易地封装在“黑匣子”中，开发人员只需直接调用其功能即可。

　　开发人员在使用COM时感到不便的一个问题是，他们必须编写附加代码来将业务逻辑程序转换成可复用的组件，同时还必须实现许多接口才能进行这种转换。最重要的是，COM要求开发人员必须手动处理复杂问题，比如：清空不再使用的组件曾占用的内存、计算组件的使用次数、建立或撤消线程和进程以及处理版本控制问题等。

　　有人可能认为，让开发人员亲自执行这类工作的主意非常好，但这也有几个弊端。首先，要开发人员一一执行上述所有工作非常困难，往往容易出错：导致应用程序错误、系统崩溃以及可怕的“DLL Hell”。另外，严格地写出所有这种附加代码，会降低开发人员的工作效率，导致延期上市。

　　这对使用Visual C++?开发系统的开发人员来说，尤其如此。而对使用Visual Basic的开发人员来说，这种情况不是很严重。Visual Basic抽象并简化了COM的许多概念，是全世界最具生产力、最流行的开发环境，但它的局限性在于：为了实现这种高生产力而不得不向开发人员屏蔽了COM的一些功能。

　　微软在2000年的专业开发人员大会(PDC)上引进的.NET框架，能自动在软件编写过程中进行“智能拼接”，使得开发人员可以集中精力编写业务逻辑，而不必编写COM基本结构。

　　什么是.NET框架?

　　.NET框架是一个多语言组件开发和执行环境，它由以下三个主要部分组成：

　　公共语言运行时。此名称不能准确反映它的全部功能。实际上，公共语言运行时在组件的开发及运行过程中，都扮演着非常重要的角色。在组件运行过程中，运行时负责管理内存分配、启动或删除线程和进程、实施安全性策略、同时满足当前组件对其它组件的需求。在开发阶段，运行时的作用有些变化：与现今的COM相比，运行时的自动化程度大为提高(比如可自动执行内存管理)，因而开发人员的工作变得非常轻松。尤其是，映射功能将锐减开发人员将业务逻辑程序转化成可复用组件的代码编写量。对编程语言而言，运行时这个概念并不新奇：实际上每种编程语言都有自己的运行时。Visual Basic开发系统具有最为明显的运行时(名为VBRUN)，Visual C++?跟Visual FoxPro?、Jscript?、SmallTalk、Perl、Python和Java一样有一个运行时，即MSVCRT。.NET框架的关键作用在于，它提供了一个跨编程语言的统一编程环境，这也是它能独树一帜的根本原因。

　　统一的编程类。.NET框架为开发人员提供了一个统一、面向对象、层次化、可扩展的类库集(API)。现今，C++开发人员使用的是Microsoft基类库，Java开发人员使用的是Windows?基类库，而Visual Basic用户使用的又是Visual Basic API集。只是简单地一用，.NET框架就统一了微软当前的各种不同类框架。这样，开发人员无需学习多种框架就能顺利编程。远不止于此的是，通过创建跨编程语言的公共API集，.NET框架可实现跨语言继承性、错误处理功能和调试功能。实际上，从JScript到C++的所有编程语言，都是相互等同的，开发人员可以自由选择理想的编程语言。

　　活动服务器页面(ASP+)。ASP+是使用.NET框架提供的编程类库构建而成的，它提供了Web应用程序模型，该模型由一组控件和一个基本结构组成。有了它，Web应用程序的构建变得非常容易。开发人员可以直接使用ASP+控件集，该控件集封装了公共的、用于超文本标识语言(HTML)用户界面的各种小器件(诸如文本框、下拉菜单等等)。实际上，这些控件运行在Web服务器上，它们将用户界面转换成HTML格式后再发送给浏览器。在服务器上，控件负责将面向对象的编程模型提供给Web开发人员，这种编程模型能提供面向对象编程技术的丰富功能。ASP+还提供一些基本结构服务(诸如会话状态管理和进程重启服务)，这些服务大大减少了开发人员要编写的代码量，并使应用程序的可靠性得到大幅度提高。ASP+还允许开发人员将软件作为一项服务来提供。通过使用ASP+ Web服务功能，ASP+开发人员只需进行简单的业务逻辑编程，而由ASP+基本结构负责通过简单对象访问协议(SOAP)来提供服务。

　　.NET框架与COM的关系

　　.NET框架的一个主要目的是使COM开发变得更加容易。COM开发过程中最难的一件事是处理COM基本结构。因此，为了简化COM开发，.NET框架实际上已自动处理了所有在开发人员看来是与“COM”紧密相关的任务，包括引用计算、接口描述以及注册。

　　必须认识到，这并不意味着.NET框架组件不是COM组件。事实上，使用Visual Studio 6.0的COM开发人员可以调用.NET框架组件，并且在他们看来，后者更像是拥有iUnknown数据的COM组件。相反，使用Visual Studio.NET的.NET框架开发人员则将COM组件视作.NET框架组件。

　　为了避免引起误解，这里需对这种关系加以特别说明：COM开发人员必须手动去做大多数.NET框架开发人员可以在运行时自动执行的事情。例如，必须手写COM组件的安全性模块，且无法自动管理模块占用的内存，而在安装COM组件时，注册条目必须放进Windows注册表中。对.NET框架而言，运行时实现了这些功能的自动化。例如，组件本身是自我描述型的，因而无需注册到Windows注册表中便能安装。

　　.NET框架与COM+的关系

　　当把COM与Microsoft事务服务器(MTS)和分布式COM(DCOM)结合在一起时，就变成了COM+。COM+提供了一组面向中间层的服务。特别是COM+提供了进程管理功能和数据库与对象连接池处理功能。在将来的版本中，它还将提供一种称为分区的功能——专门为应用程序服务提供商设计的更强大的进程隔离功能。

　　COM+服务主要面向中间层应用程序开发，并主要为大型分布式应用程序提供可靠性和可扩展性。这些服务是对.NET框架所提供服务的补充;通过.NET框架类，可以直接访问这些服务。

http://www.soft6.com/tech/16/168707.html