DCOM揭秘之三

理解简单的DCOM服务器

　　以上我们主要讲解了如何通过一个客户应用使用COM。对于客户来说，COM的编程技巧是相当简单的。客户端的应用向COM子系统请求一个特定的组件，服务器端将其传送过来。

　　实际上，对于后台的组件管理工作，还需要写很多的代码。真正的对象实现需要使用复杂的系统组件和标准的应用模块。就算是使用MFC，也是很复杂的。大多数的专业编程者都不会花时间来研究这个过程。自从COM的标准发布以来，很快就令我们明白到让开发者来自己写这些代码是不现实的。

　　当你查看实现COM的真正代码时，你会发现其中大部分都是重复的。对于这类复杂的问题，传统C++的解决之道是创建一个COM类库。实际上，MPC OLE类提供了大部分的COM特性。

　　不过对于COM组件来说，MFC和OLE并不是一个好的选择，有几个理由。随着ActiveX和微软Internet策略的推出，COM对象应该要非常的紧凑和快速。ActiveX需要COM对象可以经过网络相当快地被复制。如果你使用MFC较多，就会发现它实在太大了（特别是在静态链接时）。通过网络来传送巨大的MFC对象是不现实的。

　　或许通过MFC/OLE方法来实现COM组件的最大问题是复杂性。OLE编程是复杂的，并且大部分的编程者都不会在上面走得很远。有大量关于OLE的书，这都说明它是非常难以掌握的。

　　由于OLE的开发有不少的难度，因此微软创建了一个称为ATL（Active Template Library）新工具。对于COM编程来说，ATL是当前最实用的工具。实际上，如果你对其背后的东西没有兴趣，使用ATL向导来编写COM服务器是相当简单的。

　　这里介绍的例子都是通过ATL和ATL应用向导来创建的。这一节我们将讲解如何建立一个基于ATL的服务器，并对向导产生的代码给出了一个摘要。
　　关于代码

　　有一点你要花时间去习惯，编写ATL服务器和传统的编程是不一样的。COM服务器其实是几个独立组件的协作构成的，包括有：

　　　。你的应用

　　　。COM子系统

　　　。ATL模板类

　　　。“IDL”代码和MIDL产生的“C”头文件和程序

　　　。系统寄存器

　　要将一个基于ATL的COM应用作为一个整体看是挺困难的。即使你知道它正在做什么，还有很大一块应用你是看不到的。真正服务器中的大部分逻辑都深入隐藏在ATL的头文件中。你将不会找到一个单一的用来管理和控制服务器的main()函数。你只找到一个用来调用基本ATL对象的瘦外壳。

　　在以下的部分中，我们将把所有这些令服务器运作的部分放在一起。首先我们会使用ATL COM应用向导来创建服务器。第二步我们将加入一个COM对象和一个方法。我们将写一个进程内的服务器，因为它是最容易实现的COM服务器之一。一个进程内的服务器也不用建立一个proxy和stub对象。

　　建立一个基于DLL（进程内）的COM服务器

　　一个进程内的服务器就是一个会在运行时载入到你程序中的COM类。用其它话来说，就是一个动态链接库（DLL）中的COM对象。用传统的观点来看，一个DLL并不是一个真正的服务器，因为它会直接载入到客户的地址空间中。如果你熟悉DLL，你已经知道了许多关于COM对象如何载入和映射到调用程序的知识。

　　通常在调用LoadLibrary()时，DLL就会被载入。在COM中，你无需显式调用LoadLibrary()。在客户端的程序调用CoCreateInstance()时，所有的处理都会自动启动。CoCreateInstance需要的其中一个参数是你要使用的COM类的GUID。当服务器在编译时创建时，它就会登记了所有它支持的COM对象。当客户端需要该对象时，COM找到服务器DLL，并且自动装载它。一旦载入，DLL就拥有了创建COM对象的类库。

　　CoCreateInstance() 返回一个指向COM对象的指针，它是用来调用方法的（再这里的例子中，这个方法就是被称为Beep()的方法）。COM的一个便利之处是DLL可以在不需要的时候被自动卸载。在对象被释放和CoUninitialize()被调用后，FreeLibrary()将会被调用来卸载服务器DLL。

　　如果你对以上的都不熟悉也不要紧。要使用COM，你不需要知道关于DLL的任何知识。你所要做的是调用CoCreateInstance()。COM的其中一个好处是它隐藏了这些细节，因此你无需担心此类问题。

　　进程内的COM服务器有优点也有缺点。如果动态链接是你的系统设计中的重要一环，那么你将发现COM可提供一个极好的方式来管理DLL。一些有经验的编程者会将所有他们的DLL都写成为进程内的COM服务器。COM处理所有涉及载入、卸载的杂事，而输出DLL函数和COM函数调用只有很少的系统开销。

　　我们选择一个进程内服务器的主要理由就更简单了：它可令例子更加简单。我们不必关心如何启动远程的服务器（EXE或者服务），因为我们的服务器将会在需要的时候自动载入。我们也无需建立一个proxy/stub DLL来做marshalling的工作。

　　缺点是，由于进程内的服务器与我们的客户绑定很紧密，因此COM许多重要的“分布”特性没有展现出来。一个DLL服务器和它的客户共享内存，而一个分布的服务器将令客户端更加隔离开来。在一个分布的客户和服务器间传送数据的处理被称为marshaling。marshaling在COM上的利用是受到限制的，而在进程内的服务器中，我们无需关心这些。 Photoshop入门教程 Photoshop实例教程 Photoshop cs教程 滤镜 鼠绘 Photoshop照片处理 Photoshop视频教程 Photoshop作品展示 特效 抠图

[1] [2] [3] 下一页

复制本页网址和标题，发送给你QQ/Msn的好友一起分享

上一篇:DCOM揭秘之六

下一篇:利用套接字机制实现Flash与数据库连接