实现灵活性时，到底应该使用COM组件还是DLL？

[lop5712]

在实现灵活性时，比如实现一个基本框架，以后的人事部、商务部等都以组件形式提供，将基本框架支持的COM接口写成SDK开发文档，以使得第三方开发商可以为此基本框架开发任意插件（如：财务部）。
问题是此插件使用COM实现还是原始的DLL？如3DMAX、Winamp都使用Dll的形式，虽然它们也都注册了COM组件，但你将它们插件目录下的DLL移走，它们将不会显示那个插件的功能。
我并不是想要实现这个效果，只是想要一个标准，即使COM组件完全包含DLL，但功能不可以过量，就好象C++中函数的const修饰符，只是语义上的需求，你完全可以在你的成员函数const CString& GetName() const{...}中将后面的const去掉，但它不可以去掉一样。

[powercy]

没明白什么意思？再说明白点。

• 打赏
• 举报

回复 赞

[cxf1976]

使用com吧，实现灵活一些。
另外dll和com相同又不同,dll只是com的一种表现形式。
你说的dll应该是普通的dll。

• 打赏
• 举报

回复 赞

[lop5712]

举个例子
接口IAbc
HRESULT IAbc::A( [in] long a );
HRESULT IAbc::B( [out] long *b );
用一个COM组件实现IAbc则可实现A和B两个方法，等同的
DLL输出函数
HRESULT Abc_A( long a );
HRESULT Abc_B( long *b ) const;
这样同样实现上面的COM组件的功能
因为将一个功能作为一个COM组件来实现，则其在进程中只有一个实例，其效果和用DLL直接输出函数没有任何区别，那到底应该使用那种实现方式？应有一个标准，以其作为准则。

• 打赏
• 举报

回复 赞

[rtdb]

若是将来有可能用到其它系统上， 就不用要COM
若是想直接传送复杂的数据类型， 就不用要COM
若是不喜欢MS， 就不要用COM

若是只想在WINDOWS中用，就用COM
若是想支持多语言实现，就用COM
若是喜欢MS， 就用COM

• 打赏
• 举报

回复 赞

[lop5712]

非常抱歉，楼上的准则我不能接受，何谓复杂，你认为不复杂但他认为复杂怎么办？我当前只考虑Windows平台，但就是在一个平台下也有些应用DLL，有些应用COM组件

下面是我以为的标准：
当插件有可能在一台机子上被两个及其以上的进程中的线程调用，且两个进程可互相独立存在时，应使用COM，否则都应是DLL。
比如：Winamp的插件，因为只为Winamp一个进程用，所以使用DLL，每个DLL插件必须放在PlugIn目录下，且每个不用注册；Flash的效果插件，应当使用COM组件，因为除了Flash编辑软件这个进程外，FlashPlayer也会在IE的进程中用到效果插件，且它们两个可以完全独立存在。

使用上述标准时，用DLL有时会显得很繁杂，代码可读性很差，且只能使用全局变量，因此此时可以使用COM，但应该使用DLL，这就好象语意的需要一样

• 打赏
• 举报

回复 赞

[rtdb]

楼主已经很有主意了， 不过还是建议两种方法都去尝试一下。
与其坐而论道不如什么来着...

只说明一下，那个复杂是指“复杂的数据类型”作为参数来传递，
例如C语言的字符串数组， 或者一个结构， 或者一个类的指针什么的，
这些都是COM不直接支持的（需要转为其它方式来传）。

话说回来， 一但使用这类C特有的数据类型， 用其它语言写DLL也会很困难的。

话再说回来，在WINDOWS平台下， 新开发的系统， 用COM的肯定会比DLL多，
COM毕竟要先进。楼主的“否则都应是DLL”不敢茍同。

• 打赏
• 举报

回复 赞

[lop5712]

多谢指点

• 打赏
• 举报

回复 赞