914事件发生的那天，Ben_Ladan(兰企鹅)兄在 CSDN 的 BCB 版发了一个贴，问起一个关于用 BCB 进行 MIDAS 开发的问题。刚好这个问题是我会的，因为一年多前（准确的说是2001年9月4日） luhongjun(过江项羽)兄曾在 BCB 版发过一个关于 MIDAS 开发的贴子，其中就有类似的问题，当年解决项羽兄的两个问题也是 BCB 版的高人：holyfire(^@L@^)和ALNG(?)。很高兴这次的讨论又加入了几位新的高人：kingcaiyao(AKing)、PPower()等，将这个问题的研究更加深化了，相信看过此贴的人都获益非浅。我把这些内容整理了一下，并作了一些进一步的分析。
为方便讨论，先写一个例子程序，与 Ben_Ladan 兄的程序及 luhongjun 兄的不同，但原理是一样的：
服务端程序如图所示：
这是一个普通的 RemoteDataModule 式的 MIDAS 中间服务器。使用一个 ADOConnection 、一个 ADODataSet 、一个 DataSetProvider 。其中 adoTest(ADODataSet) 的 CommandText 属性没有设置。在 IrdmTest 接口中增加一个方法： SetQuery ，带有一个 BSTR 类型的参数：aTableName ，如下图：
刷新后生成 SetQuery 方法的实现，完成其实现如下（其中标记为红色的 m_DataModule 是后面要讨论的问题之一）：
STDMETHODIMP TrdmTestImpl::SetQuery(BSTR aTableName) { try { m_DataModule->adoTest->CommandText = AnsiString( "select * from " ) + aTableName; } catch( Exception &e ) { return Error(e.Message.c_str(), IID_IrdmTest); } return S_OK; }
将服务端程序编译注册。然后写一个客户端程序，如下图所示：
生成两个按钮的事件响应并实现，代码如下（下面标记为红色的部分是另一个要讨论的问题）：
//--------------------------------------------------------------------------- // SetQuery void __fastcall TForm2::Button1Click(TObject *Sender) { Conn->Open( ); IrdmTestDisp v; v.Bind( ( IDispatch * )Conn->AppServer ); try { v->SetQuery( WideString( Edit1->Text ) ); cdsTest->Open( ); } catch ( ... ) { } v.Unbind( ); // 这里就可以操作数据了 } //--------------------------------------------------------------------------- // CloseAll void __fastcall TForm2::Button3Click(TObject *Sender) { cdsTest->Close( ); Conn->Close( ); } //---------------------------------------------------------------------------
上面这个程序是可以正常运行的。现在可以开始讨论前面说的两个问题了：
为什么在服务端必须使用 m_DataModule 来访问远程数据模块，而不能用 rdmTest 这个全局指针变量？ 为什么在客户端必须使用 Bind( ( IDispatch * )Conn->AppServer ) 来绑定服务端的调度接口（dispinterface），而不能用 BindDefault( ) 来绑定？首先来看第一个问题：熟悉 Delphi 的人一定会很奇怪 SetQuery 为什么是 TrdmTestImpl 类的成员，而不是 rdmTest 类的成员，而且在 Delphi 中，根本就没有 TrdmTestImpl 类。这是因为 Delphi 和 C++ Builder 在 COM 方面的实现技术不同所致，在 Delphi 中是用 Borland 自己开发的 Framework : DAX 的，而在 C++ Builder 中是用 ATL 来实现。看看 DataBrk.pas 单元中 Delphi 的 RemoteDataModule 和 C++ Builder 的 RemoteDataMoudle 就知道了，下面是一个类图：
图中的 TCRemoteDataModule 就是为 C++ Builder 准备的 RemoteDataModule 类，它与 Delphi 所用的 TRemoteDataModule 类最大的不同就是：它没有实现 IAppServer 接口，而 TRemoteDataModule 则有。图上 TrdmTest 即为前面例子程序中的 RemoteDataModule ，而 IDrdmTest/TDrdmTest 是为了对比加上的 Delphi 相应的接口和类。可见， Delphi 只要这几个接口/类即可实现 MIDAS 的核心功能，但 C++ Builder 则不行，它还没实现 IAppServer 接口。
那么 C++ Builder 是如何实现的呢？看下面这个类图，它是根据 rdmTestImpl.h 文件的内容画的（注意：下图中的Stereotype被用来说明模块板参数）：
当然，在 rdmTestImpl.h 文件中用了宏来实现 TrdmTestImpl 类的派生，上图是将其展开后并向上了几个层次。很明显，这是一个多重派生，TrdmTestImpl 类从 ATL 的模板类 CComObjectRootEx 和 CComCoClass 以及 IAppServer 接口的实现类 IAppServerImpl 中派生出来的，而在前一图中： TrdmTest 是从 VCL 类 TCRemoteDataModule 中派生。我们知道 VCL 类是不支持多重派生的，所以在 C++ Builder 中不得不作另外的处理。
首先，可以看到 IrdmTest 接口是从 IAppServer 派生来的，所以 SetQuery 是 IrdmTest 的一个方法，当然也就是 TrdmTestImpl 的成员，而不是 TrdmTest 的成员。图中 IDispatchImpl, IAppServerImpl, TrdmTestImpl 三个类分别是 IDispatch, IAppServer, IrdmTest 三个接口的实现，其中 IDispatchImpl 是从 IrdmTest 接口派生的，这是通过模板来实现的。
因为在 MIDAS 中，客户端是通过创建一个 Remote COM 对象来调用服务端的 IAppServer 接口的，即当客户端连接到服务端来时，服务端将启动一个 IAppServerImpl 的实例。为了连接 RemoteDataModule ， IAppServerImpl 类通过模板实现了一个 TrdmTest 类的实例： m_DataModule ，因为每个客户端连接对应了一个 IAppServerImpl 的实例，也就是说，每个客户端有一个各自独立的 RemoteDataModule 实例。下面这段代码来自 atlvcl.h 文件，也就是bufanxiong(bufanxiong)兄贴出的那段代码，它说明了 IAppServerImpl 是如何通过 m_DataModule 连接 RemoteDataModule 的。（注意：其中的 DM 类其实是通过模板参数传入的类型，在本例中即是 TrdmTest ）
DM* m_DataModule; // The Core. // Note: This data module _must_ descend from TCRemoteDataModule. IAppServerImpl() { m_DataModule = new DM(NULL); } ~IAppServerImpl() { m_DataModule->Free(); }
而那个全局的 rdmTest 对象指针指向的肯定不会是与当前 IAppServerImpl 实例关联的 RemoteDataModule 实例，所以在问题一中，必须使用 m_DataModule 而不能用 rdmTest ，否则调用 SetQuery 设置 CommandText 属性的 ADODataSet 肯定跟 ClientDataSet Open 时打开的那个 ADODataSet 不是同一个，当然会出错。基本上 PPower() 兄的理解是比较正确的，不过要注意的是 IAppServerImpl 不是来自于 ATL 的，它是 BCB 的 MIDAS 的一部分，至于用 ATL 实现的 MIDAS 是否会比用 DAX 实现的 MIDAS 要快就很难说了。但可以肯定的是用 DAX 做肯定比用 ATL 简单。
再来看第二个问题，为什么不能用 BindDefault 。
首先看看 Server_TLB.h 文件中 IrdmTestDisp 类中 BindDefault 是如何实现的：
// *********************************************************************// // DispIntf: IrdmTest // Flags: (4416) Dual OleAutomation Dispatchable // GUID: {1BB59F63-93D0-4FC2-9D5C-5DAE096C38D2} // *********************************************************************// template<class T> class IrdmTestDispT : public TAutoDriver<IrdmTest> { public: ... HRESULT BindDefault() { return OLECHECK(Bind(CLSID_rdmTest)); } typedef IrdmTestDispT<IrdmTest> IrdmTestDisp;
它调用了 TAutoDriver 模板类中 Bind 函数的一个重载版本，见 utilcls.h
// Bind via GUID // template <class DISPINTF> HRESULT TAutoDriver<DISPINTF>::Bind(const GUID& clsid) { LPUNKNOWN punk = 0; HRESULT hr = CoClassCreator::CoCreateInstance(clsid, IID_IUnknown, (LPVOID*)&punk); if (SUCCEEDED(hr)) { // We should have a valid interface pointer // _ASSERTE(punk /* Must have valid IUnknown pointer */); // Run Object - just in case // hr = ::OleRun(punk); // Bind to running IUnknown // if (SUCCEEDED(hr)) hr = Bind(punk); // Release IUnknown // punk->Release(); } return hr; }
请注意上面标记为红色部分的代码， Bind 在这里调用了 CoCreateInstance 来创建了一个新的服务端实例，即服务端会创建一个新的 IAppServerImpl 实例，它与客户端程序通过 DCOMConnection 连接来创建的那个 IAppServerImpl 实例是相互独立的。这就意味着：如果客户端通过 BindDefault 连接到服务端，然后调用 SetQuery 进行操作，当客户端调用 IrdmTestDisp 类的 Unbind 函数时，此 IAppServerImpl 实例将被释放，也就是说刚才用 SetQuery 所作的操作被全部作废，对那个与 DCOMConnection 连接的 IAppServerImpl 实例没有任何影响，因为它们根本不是同一个，当然会出错了。
再看看如果改用 Bind( ( IDispatch * )Conn->AppServer ) 又是如何呢？
这时将调用 TAutoDriver 模板类中 Bind 函数的另一个重载版本，见 utilcls.h
// Bind via IUnknown // template <class DISPINTF> HRESULT TAutoDriver<DISPINTF>::Bind(LPUNKNOWN punk) { _ASSERTE(punk /* Must bind to non-NULL interface pointer */); HRESULT hr = E_POINTER; if (punk) { DISPINTF *disp; hr = punk->QueryInterface(__uuidof(DISPINTF), (LPVOID*)&disp); if (SUCCEEDED(hr)) Bind(disp, false /* Don't AddRef */); } return hr; }
这时就不会新建实例，而是通过 QueryInterface 来取得相应的实例指针了。至于为什么要把 Conn->AppServer 转为 IDispatch * 是因为： AppServer 是 Variant 类型（为了方便进行 Late binding 方式调用），而 Variant 类型是 IDispatch * 的兼容类型， IDispatch 又是从 IUnknown 派生的，所以需要先转换一下，否则会出现类型不兼容的编译错误。
最后顺便说一下 Ben_Ladan(兰企鹅)兄提到的另一个问题，在 Server.cpp 中：
TComModule _ProjectModule( 0/*InitATLServer*/); TComModule &_Module = _ProjectModule; // The ATL Object map holds an array of _ATL_OBJMAP_ENTRY structures that // described the objects of your OLE server. The MAP is handed to your // project's CComModule-derived _Module object via the Init method. // BEGIN_OBJECT_MAP(ObjectMap) OBJECT_ENTRY(CLSID_rdmTest, TrdmTestImpl) END_OBJECT_MAP()
其中的 _Module 是做什么用的？
PPower() 兄的解释是不对的。因为下面那段关于 MAP 的代码并非用于 VCL 类和 C++ 类之间 MAP 的，但它跟 _Module 也不是没有关系。
首先，见 atlcom.h 中这三个宏的定义（因为代码太长，作了断行处理）：
#define BEGIN_OBJECT_MAP(x) static _ATL_OBJMAP_ENTRY x[] = { #define END_OBJECT_MAP() {NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL}}; #define OBJECT_ENTRY(clsid, class) {&clsid, class::UpdateRegistry, \ class::_ClassFactoryCreatorClass::CreateInstance, \ class::_CreatorClass::CreateInstance, NULL, 0, class::GetObjectDescription, \ class::GetCategoryMap, class::ObjectMain },
可见这段 MAP 只是用于建立一个 _ATL_OBJMAP_ENTRY 类的数组，下面是 atlbase.h 中关于这个类的定义：
struct _ATL_OBJMAP_ENTRY { const CLSID* pclsid; HRESULT (WINAPI *pfnUpdateRegistry)(BOOL bRegister); _ATL_CREATORFUNC* pfnGetClassObject; _ATL_CREATORFUNC* pfnCreateInstance; IUnknown* pCF; DWORD dwRegister; _ATL_DESCRIPTIONFUNC* pfnGetObjectDescription; _ATL_CATMAPFUNC* pfnGetCategoryMap; HRESULT WINAPI RevokeClassObject() { return CoRevokeClassObject(dwRegister); } HRESULT WINAPI RegisterClassObject(DWORD dwClsContext, DWORD dwFlags) { IUnknown* p = NULL; if (pfnGetClassObject == NULL) return S_OK; HRESULT hRes = pfnGetClassObject(pfnCreateInstance, IID_IUnknown, (LPVOID*) &p); if (SUCCEEDED(hRes)) hRes = CoRegisterClassObject(*pclsid, p, dwClsContext, dwFlags, &dwRegister); if (p != NULL) p->Release(); return hRes; } // Added in ATL 3.0 void (WINAPI *pfnObjectMain)(bool bStarting); };
这下很清楚了， _ATL_OBJMAP_ENTRY 类是用于 COM 对象初始化的，它提供了对象的注册/反注册/CreateInstance/GetClassObject（用于取得 ClassFactory）等功能。当一个程序中包含了多个 COM 类时就需要用这个数据来维护各个类的初始化实现。
那么这些初始化实现与 _Module 有什么关系？
其实 _Module 很像 DAX 中的 ComServer 。下面的代码来自 atlmod.h 中， _Module 和 ObjectMap（就是前面用宏定义的数组）就是用在这里了。
// _Module is assumed to be a reference to a TComModule // User may define _Module to be a ref. to an instance of a class derived // from TComModule. // typedef TATLModule<CComModule> TComModule; extern TComModule &_Module; ... // To be defined in the Project's source // extern _ATL_OBJMAP_ENTRY ObjectMap[];
仔细研究 atlmod.h 中关于 TATLModule 类型的实现就可以发现，它的构造函数调用了成员函数 InitATLServer ，这就是为什么在 Server.cpp 中会有：TComModule _ProjectModule( 0/*InitATLServer*/);，而在 InitATLServer 中，_Module 调用了 CComModule 的成员 Init 进行初始化，其中用到的一个参数就是 ObjectMap 。
至此 _Module 的用途已经完全清楚了：它是 COM 应用程序的初始化类的实现对象，而它是通过 ObjectMap 数组进行对 COM 应用程序中不同的 COM 类对象进行初始化的。
下面这段代码来自用 BCB 写的 DLL 方式的 COM 。四个初始化函数据都被映射为 _Module 的相应函数调用了。
// Entry point of your Server invoked to inquire whether the DLL is no // longer in use and should be unloaded. // STDAPI __export DllCanUnloadNow(void) { return (_Module.GetLockCount()==0) ? S_OK : S_FALSE; } // Entry point of your Server allowing OLE to retrieve a class object from // your Server // STDAPI __export DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID* ppv) { return _Module.GetClassObject(rclsid, riid, ppv); } // Entry point of your Server invoked to instruct the server to create // registry entries for all classes supported by the module // STDAPI __export DllRegisterServer(void) { return _Module.RegisterServer(TRUE); } // Entry point of your Server invoked to instruct the server to remove // all registry entries created through DllRegisterServer. // STDAPI __export DllUnregisterServer(void) { return _Module.UnregisterServer(); }
这种技术性的讨论是非常有益的，为了写本文，我在这一周里读了 BCB 中的很多源码，觉得大有收获，希望本文对读者也有一定的帮助。
[Mental Studio]猛禽 Sep.22-02
本文地址：http://com.8s8s.com/it/it29534.htm