到底用不用COM

[homeg]

公司有个软件产品，Windows桌面应用软件，编写语言为标准C和C++，开发工具VC6，由十几个动态库和静态库工程组成，库之间接口还比较清晰，部分库分了内部层次。

为了以后产品的升级、代码的重用和高效率的开发，我现在考虑逐步将部分模块封装成COM组件，但我没有使用过COM, 因此有一些问题请教大家。

1、印象中Activex 技术好像比COM早？后来统一到COM，应该说COM包含Activex，如果我做好了COM组件，转成Activex控件是否很容易？

2、COM技术好像很复杂，我担心过多的关心技术实现的细节反而耽误了产品的真正应用实现？如果这样，现在这种划分清晰的类库和动态库可能还好一点

3、大家经常拿COM CORBA EJB j2EE比较，我怎么感觉国内使用corba ejb j2ee的很少，com好象也不多，尤其在桌面应用上？corba项目我接触过一个，很烂，感觉新技术新规范不一定能出好产品 好软件

用不用com 大家提点意见，谢谢

[realdreamer]

不用, 丢了算了. 改为j2ee 或.net吧

[Analyst]

1、ActiveX是从OLE中发展出来的，主要是将对象嵌入和连接到其他应用程序中，是COM技术的一种应用。把一个对象做成ActiveX对象并不是很困难。
2、COM技术是比较复杂，因为涉及到windows应用层面各个方面，不过掌握这些技术规范对于开发是很有好处的，因为很多都是我们在实际开发过程中碰到的问题，比如说对象的生命周期，接口查询，线程模型，枚举对象，事件，永久对象，DCOM等等，COM技术为我们提供了标准的解决方案。其次按COM规范实现的组件可以达到很高的复用性，实现二进制级别的兼容性，实现跨进程，跨语言的调用，在这种开放式的架构下，你的产品就更容易的被集成和整和。
3、corba ejb j2ee等等都是面向企业级应用的，显然是不适合桌面应用的，COM在桌面上的应用是非常广泛的，特别是MS的产品几乎都是构筑于COM之上的。

[ayqlj]

楼上的分析很有道理

[Frank123]

公司要我写个com给web程序调用，看了资料，正准备做。希望高手继续讨论，关注！

[nlstone]

COM的复杂在于使用面向接口的程序架构,套间、连接点、聚合等,如果着力于将普通类封装为COM接口,则不必太深究于COM的原理.
这样的封装是很简单的.同样,COM的调用也是简单的.因此不必担心耽误了产品的实现。

[flyingjust]

AXTIVEX 也是com对象 只是他偏重于界面的表示。 而com组件是业务逻辑的封装。
Activex控件也可使用com组件。 我们公司就在用com＋ ， 现在转到。NET框架以前的那些com组件一样能用：） 节省了很多开发时间。

[zhp80]

Analyst() 对COM讲析得很透彻
不过，nlstone(天外流星) ：如果COM没有使用面向接口的程序架构,套间、连接点、聚合等,只是着力于将普通类封装为COM接口，那用它干什么？做一些WinAPI 的DLL好了
Frank123(Frank) 提的是应用COM的一种需求：利用它的二进制级别的兼容性，实现开放式的架构下的集成和整和

[homeg]

没有人提出真知灼见吗！？

难道大家都沉迷于技术的实现，而不去关注技术的来历以及未来的发展

[homeg]

analyst:
讲的很在点
不知道国内有那些产品用COM，而且基本上全部是由COM搭购的

nlstone:
我只是扫了以下<COM原理与应用> <COM本质论>，觉的很复杂，第一步也不想懂太多，有没有<VC技术内幕>那种，例子和概念结合的很好的书，推荐一下

flyingjust:
有一个动态库，包含两个类，一个是自定义类，另一个是对话框类，自定义类访问数据库并向外部提供接口，对话框类显示一个数据库某些数据的对话框，这样一个东西封装成ActiveX好，还是COM好

我如果封装成COM，首先自定义类中所有 Public函数我都必须弄一个COM接口函数，是不是？

另外还要提供一个接口函数显示对话框？



zhp80:
封装成DLL，我必须使用DLL对应的头文件, 封装成COM，其他程序调用时就不需要头文件，但是要知道COM提供的函数接口，是不是？

谢谢大家

[zzyx]

搬板凳
听讲

[zhp80]

没错，封装成COM，其他程序调用时就不需要头文件，至于COM提供的函数接口，如果你指的不是文档的话，使用者完全可以自己查出来，比如你在VC、VB、Delphi中引用了一个Coclass后，就知道了它的接口、属性、方法，COM有这种机制

向你说的那种情形，不知我理解的对不对，我一般喜欢用COM，做成CoClass，那个对话框是该CoClass的一个方法，比如 Edit or Browse ...

zzyx(菜农):你----搬板凳----听讲---？-！-？-！-？

[mlin2000]

个软件产品，Windows桌面应用软件，编写语言为标准C和C++，开发工具VC6，由十几个动态库和静态库工程组成，库之间接口还比较清晰，部分库分了内部层次。
to homeg ()
如果该软件只是使用到vc开发，而没有使用vb、或者java等其它语言，那么做成com接口封装，有些得不偿失。
首先，需要学习com技术，而且不容易学。
在做的过程中，可能会由于不熟悉，和调试困难，而出现封装漏洞，留下安全隐患。
com技术主要是用来，解决不同语言开发同一个系统的整合问题。主要，用于复杂的系统集成
开发，以及web开发。

[nlstone]

to: zhp80(zhp80)
你难道不明白楼主的意思吗?楼主要做的正是这样一种普通"封装",一来是熟悉COM技术,二来是将程序"结构化",提高模块的独立性和重用性,结构清晰一些.如果真要等到楼上明晰COM原理,少说也要半年的时间吧.黄花菜都凉了.

to: 楼主
COM的实用书籍:《COM/DCOM编程指南》
国内外完全基于COM的大型桌面产品并不多，前年有一个不权威的统计，全球不过十数家。
国内我只知道开目的三维CAD是全COM的。
封装成COM简单说就是要为每一个自定义类增加一个接口基类（集中所有的public函数）。
调用COM需要知道接口ID和类ID

[visualc6]

gz

[maohbao]

大家多讲一点，我好学一学！

[zzyx]

俺搬了板凳，听听讲座有啥不行吗？现在没事，俺也要发发言了：

以上dx的话俺都同意，但说COM，别忘记了它还有的面向对象的特性

从规范上来讲，二进制兼容，位置透明性，接口的唯一性等等特性，方便了COM的使用者（客户端），只要符合规范的调用方法，都可以使用用它。

从oo的角度看，其封装的特性更明显一些。当然，你的dll，或者lib，都有封装的能力，但com的方式更明显一些，使用com，会强迫你使用oo的方式来规划，思考。

设计实现com的过程中，你面向的是类，接口，接口方法，而dll，lib面向的是过程。

在使用上，com在使用过程中你会很清晰地看到到底是哪个对象在工作，而dll，lib一般来说你看到的都是函数。简单的例子，你的xx.dll提供函数a，yy.lib提供函数b
你在使用的时候，调用a，或者调用b，从代码上看不出到底是哪个东西在干活
而用com方式，一般来说，你都要使用xx->a或xx.a，yy->b或yy.b的方式。
显然com封装得更彻底。

至于封装的意义，俺就不说了。


对于com和activex，应该说，activex是com的规范的具体应用，activex是实现了更多的已经
定义的接口的com组件，如IPesistxxx，...之类的

对于com开发的复杂度，俺认为，一个优秀的有经验的vc程序员，从接触到能进行简单的
组件开发与实现，用不了一周的时间。而对于一个桌面系统来说，很多的复杂的com技术
可能不会涉及到。

至于.net,j2ee,cobra等组件技术，在目前的一般桌面系统中，没有太大的应用可能，而com与系统结合更自然一些。也就是说，在桌面系统中如果考虑组件技术，com肯定更有优势（目前）。

但从具体情况分析，既然你们的东西都已经用dll，lib做了比较好的封装，重新用com实现
要考虑是否有必要了，还要考虑开发成本了。

如果你不需要其他开发语言，开发环境也来使用你已经封装的功能的话，那么二进制兼容就没有多大意义。
如果你不用分布式，那么位置透明性也失去意义
如果你的东西不与操作系统的其他组件、应用等进行操作配合，那么接口的唯一性也没有什么意义了

[teddyma]

我感觉改成com也不太难吧，一个一个组件来，保证好清晰的接口，com在结构上还是很清晰的

[ffoieoi]

如果你急于实现的话我建议你还是不要用COM 了，因为COM 如果你不过它的原理不理解的话那到时出了问题，那就有你的受了， 不过你如果是不急的话， 我认为用ＣＯＭ 好因为COM 的确是一个不错的东东^_^.