深入探索MS COM开发框架 之 MFC和ATL/1

深入探索MS COM开发框架 之 MFC和ATL

 

 

 

                              By TomHornson(@)hotmail.com 

------------------------------------------------------------------

 

文章索引：

 

一、概述和待剖析宏罗列

 

二、MFC、ATL COM支持原理概述

 

三、宏剖析

 

☆      ☆ MFC篇

 

PART1----接口基础构造的由来

 

PART2 ----深入CCmdTarget看一看COM三大元素的实现

 

PART3------类厂的由来

 

PART4-------自动化支持

 

PART5-------组件得以使用的纽带：几个核心函数

 

☆      ☆ ATL篇

 

PART1----几个核心模板类介绍

 

PART2----模板撑起的天空 : 接口的由来

 

PART3-------自动化支持

 

PART4------深入核心模板类

 

PART5-------组件得以使用的纽带：几个核心函数

 

---------------------------------------------------------------------------

 

 

 

COM是出了名的难缠.原因在于它本身的设计灌注了大量的细节处理,九曲十八弯,令人迷惑.

 

然而MS惯用的宏手法,也是令很多人迷惑、久久不得思路.那么MFC、ATL用宏手法来提供对

COM开发的支持,就更加令人…了.下面我们就进程内组件开发探讨一下MFC、ATL对COM开

 

发的基础支持是怎样实现的….

 

 

一、概述和待剖析宏罗列

 

 

 

首先给你一个关于COM结构大致的描述 : 在组件(dll,exe,ocx等)内,存在大量的组件类

 

(CoClass),每个组件类维护N多的接口(interface),接口背后维护N的方法.自然还有类厂

 

(ClassFactory),类厂是组件类的平行类.

 

不错,那么MFC、ATL是怎样将上述的结构实现的呢 ？

 

针对MFC我们需要剖析的宏罗列于下：

 

存在组件类.h和.cpp文件中的宏：

    1. DECLARE_DYNCREATE(CSAM)

      IMPLEMENT_DYNCREATE(CSAM, CCmdTarget)[.cpp]

 

简要说明：支持RTTI和动态创建类对象能力.

 

关于此,下面不会详细讲解.

 

欲了解更多细节者可参见

 

《深入浅出MFC》,原理相同

    2. DECLARE_MESSAGE_MAP()

 

      BEGIN_MESSAGE_MAP(CSAM, CCmdTarget)[.cpp]

 

END_MESSAGE_MAP()

 

简要说明：维护消息处理系统,原因在于MFC仍然

以CwinApp对象为核心.

 

          对于此,下面不会详解,

 

          欲知详情,参考《深入浅出MFC》.

 

3.DECLARE_OLECREATE(CSAM)

     IMPLEMENT_OLECREATE(CSAM, "MFCCOM.SAM",

 

0x43d242f9, 0x4f7e, 0x4cbb, 0xae, 0xda, 0x77, 0x8d, 0xa1, 0x16, 0xd0, 0xd9)

 

简要说明：创建类厂对象,且将类厂和组件类关联,

 

          为通过CLSID创建类实例提供保证.

 

4.DECLARE_DISPATCH_MAP()

 

      BEGIN_DISPATCH_MAP(CSAM, CCmdTarget)[.cpp]

 

END_DISPATCH_MAP()

 

简要说明：支持自动化分发,事实上,

 

          这里体现MFC对COM支持的真正意图,

 

          因为MFC默认派生的接口为dispinterface

 

          (纯dispatch接口),具体细节下面会描述.

 

5.DECLARE_INTERFACE_MAP()

     BEGIN_INTERFACE_MAP(CSAM, CCmdTarget)[.cpp]

 

      INTERFACE_PART(CSAM, IID_ICOM, Dispatch)

 

     END_INTERFACE_MAP()

 

简要说明：创建接口映射表,这里的手法在MS的FrameWork中随处可见

 

          虽然可能细节的实现不同.

 

    在dll主文件中的： [xxx.cpp]

 

1.AFX_MANAGE_STATE(AfxGetStaticModuleState())

 

简要说明：这里是模块的状态管理.

 

很重要,它维护关于程序的

 

大量信息,我们将讨论其中的类厂表.

 

2. COleObjectFactory::RegisterAll()

 

简要说明：在dll初始化时,注册所有的类厂.

3. AfxDllGetClassObject(rclsid, riid, ppv);

 

简要说明：根据rclsid获取类厂指针.

 

  几个重要的函数：

 

1.        EnableAutomation()

 

简要说明：存在于各组件类的构造函数中

 

          使得CcmdTarget内含的xDiapatch首先获得

 

另一个内含的实现Idispatch的对象的vtable,

 

从而使得programmers自建的接口类成为真正的

 

实用品.

 

          这里有点复杂,详细的下面说明.

 

2.        AfxOleLockApp()

 

简要说明：存在于各组件类的构造函数中

 

          自然这个组件类须是Creatable By ID的

 

          才会显式.

 

          创建组件对象时,锁定App,进入临界区.

 

3.        AfxOleUnlockApp()

 

简要说明： 存在于各组件类的构析函数中

 

           自然这个组件必须是Creatable By ID 的,

 

            才会显式.

 

            退出临界区.

 

           是否OLE 自动化创建的所有对象销毁,

 

是则终止应用程序，在析构函数中调用.

 

4.        CCmdTarget::OnFinalRelease()

 

组件类对象的最后引用释放后,进行的收尾工作.

 

 

 

针对ATL我们需要剖析的宏罗列如下：

 

  在组件类.h文件中的宏：

 

  在.h文件中：

 

  1. DECLARE_REGISTRY_RESOURCEID(IDR_SIM)

    简要说明：支持用注册表脚本注册组件,脚本

 

在ATL中作为资源的一种.

 

2.DECLARE_PROTECT_FINAL_CONSTRUCT()

    简要说明：防止组件类对象被删除.

 

3.BEGIN_COM_MAP(CSim)

 

COM_INTERFACE_ENTRY(ISim)

 

           COM_INTERFACE_ENTRY(IDispatch)

 

END_COM_MAP()

 

简要说明：生成COM映射表,其作用与MFC的接口映射表作用是一样的.

 

  在.cpp文件中：[xxx.cpp]

 

5. BEGIN_OBJECT_MAP(ObjectMap)

 

OBJECT_ENTRY(CLSID_Sim, CSim)

 

END_OBJECT_MAP()

 

简要说明：生成组件类表,保存所有组件类的大量信息,包括

              CLSID、组件类的类工厂、更新注册成员函数的指针、

 

          获得描述成员函数的指针、创建组件类实例成员函数的指针等.

 

          这里也是一个关键之所在.

 

我们发现上面的MFC和ATL宏大有不同.是吧,事实上它们实现的手法也是大不相同的.

 

 

 

二、MFC、ATL COM支持原理概述

 

 

 首先我们必须清楚：MFC、ATL支持COM的手法是不一样的.

 

       MFC是通过嵌套类,而ATL是通过多继承.

 

        MFC支持手法概述：在一般的嵌套类解决方案中,嵌套类对象中需要维护一个指向

 

包裹类对象的指针,这样才能在接口(其实是嵌套类对象)之间转移,并实现与包裹类

 

的本身的通信.然而由于Programmers并不需要自己处理在QueryInterface时保证

 

接口指针指向正确的地址.事实上,ATL手法也不需要.所以MFC在具体实现上,

 

采用了MS的惯用手法：建偏移量表.表中记录IID和接口vtable与包裹类对象地

 

址this之间的偏移量.这样,在得到组件类的地址时,就可以得到接口的地址,从而

 

调用方法.自然,这里还有一个你感觉不到的问题：不采取特殊的手段

 

在接口指针级回到包裹类会又是一问题,然而MFC在这个问题上的解决方案是：

 

早就将嵌套类的AddRef、Release、QueryInterface,转移到包裹类的调用.

 

这样还怕进去了回不来吗 ? 这是在xDispatch中实现的.

 

没办法MS就钟情与data-driven,而且它产品中,这种手法的确玩的炉火纯青.

 

我实验了通过在嵌套类中维护包裹类指针,事实上的确比这里的

 

方法不好控制.

 

这里的一切手段的由来,都是针对解决类嵌套的特征的.

 

值得讲一下的是,这里使用的手法有组件的聚合之风范.你就带着这份感觉来

 

透彻的理解聚合和这里对嵌套的处理吧…

 

ATL支持手法概述：ATL的支持手法,可能很贴近你的思维.组件类从任意的接口继承,

 

        这样就可以利用接口在C++中的虚特征实现方法,自然同于MFC,接口必须共享

 

一套AddRef、Release、QueryInterface实现.这也是由C++的虚机制保证的.