3,248
社区成员
发帖
与我相关
我的任务
分享开发com我是应该学习哪个MFC还是ATL？
我刚刚开始学习com组件技术，开发com我是应该学习MFC还是学习ATL呢？请给我指一条明路，最好再阐述一些理由，谢谢！
...全文
请发表友善的回复…
发表回复
laker_tmj 2005-05-30
- 打赏
- 举报
up learn
蒋晟 2004-11-04
- 打赏
- 举报
问：我通常使用ATL来编写组件，但是我的同事更喜欢MFC。更加复杂的是，我不断听说VB也能编写组件。
我和我的同事在讨论用何种环境来编写组件。我想知道，我们该使用MFC还是ATL?什么时候两者都用？什么时候应该用VB代替C++?
答：很高兴你用C++来编写组件。这是理解COM工作机制的最好方法。懂得了COM原理之后，你可以使用一些工具，例如VB或VC来加速你的代码的编写。尽管一些其他的语言，例如Java也是很好的编写组件的语言，但是我不知道是否有对应的向导来快速生成COM组件骨架。
通常编写组件需要编写如下代码
编写COM类并且实现IUnknown，这包括引用计数机制和接口查询机制
添加IDispatch或者双接口使得组建可用于脚本环境
编写一个类厂
自注册
适当的入口函数(DLL)或者注册(EXE)
选择适当的线程套间
如果你不使用任何类库，你需要负责上述代码的正确性。
MFC用于基于Windows的开发。如果你对MFC的根基——窗口过程和句柄的封装——有所了解，那么你可以避免编写老式的大型switch窗口过程。MFC还提供了广泛的编程模型，例如文档视图框架和活动文档，以及有用的用户界面，例如可停靠控制栏和切分窗口。
基于历史的原因，MFC和COM是基本上独立发展的。COM的普及使得MFC不得不在语言中加入OLE和COM支持——以一个相对繁琐的方式。MFC在CCmdTarget类中实现COM支持，使得程序员们可以用几个宏就可以声明和实现COM相关的操作。BEGIN_INTERFACE_PART和END_ INTERFACE_PART声明一个嵌套类，DECLARE_OLECREATE和IMPLEMENT_OLECREATE声明和实现一个类厂，用类似于消息映射的机制编写接口查询。这样做的优点是可以在派生类中重载一个接口的实现，坏处是需要为每个嵌套类编写自己的IUnknown实现。由于这样的实现很容易用宏实现，所以我觉得MFC居然没有提供这样的宏实在是一件很奇怪的事。
MFC是一个快速编写大型程序的框架，应用程序向导可以在几秒钟之内生成一个完全可以工作的应用程序骨架，而类向导生成消息处理和自动化代码是小菜一碟。MFC同时还有很好的OLE支持——拖放、扩展，活动文档——使得编写大型组件更加迅速。引入MFC的代价是大约1兆的内存，以及性能和发布的问题。
ATL是那些懒得一次又一次编写QueryInterface而又不想跟随控件那个很大的MFC运行时刻库的人搞出来的。ActiveX在网络上大行其道的时候，互联网的带宽还很小。尽管用MFC可以迅速开发ActiveX组件，但是MFC的再发布对于当时的网络是一个严重的问题。ATL是一个轻量级的框架，主要是提供了编写组件的向导、模板和宏，以及一些简单的平台SDK支持。用它可以迅速编写很小的组件和ActiveX控件，但是这也意味着程序员需要编写部分原来MFC封装了的代码，比如通用控件的操作。
不幸的是，一些观察者认为既然MFC和ATL都提供了COM支持，那么他们就是竞争者。通常这是错的。两个框架都提供了ActiceX控件向导，但是MFC的实现更加获益于类向导、平台SDK的封装和MFC架构——这也增加了需要发布的字节数——而ATL需要你对COM有更深的了解。ATL代码中平台SDK的操作更少——部分是因为复杂度，部分是因为MFC有更好的平台SDK封装——而COM的接口，例如容器、集合等等实现更多。
尽管ATL的应用程序向导中增加了MFC支持这个选项，但是引入MFC也失去了选择ATL的大部分理由——不需要发布那个好几兆的MFC支持库。建议的方式是参考MFC的源代码，尽可能自己实现需要的MFC类。
VB是快速开发的一个很好的工具。它自动替你实现了组件创建、接口查询、引用计数和组件的生命期问题。通常你要做的只是实现接口。同时如果你添加了一个到组件类型库的引用，那么你可以在自动完成功能中看到它会自动提示接口的成员。VB的优点在于快速开发，缺点是降低了灵活度，以及混淆了接口及其实现。区分接口及其实现是COM的核心之一。
总体来说，使用VB不需要对COM有深入的了解，而ATL提供了更多高级的COM支持。MFC是这两者之间的一个折衷，同时有大量的平台SDK封装和类向导可以利用。
我和我的同事在讨论用何种环境来编写组件。我想知道，我们该使用MFC还是ATL?什么时候两者都用？什么时候应该用VB代替C++?
答：很高兴你用C++来编写组件。这是理解COM工作机制的最好方法。懂得了COM原理之后，你可以使用一些工具，例如VB或VC来加速你的代码的编写。尽管一些其他的语言，例如Java也是很好的编写组件的语言，但是我不知道是否有对应的向导来快速生成COM组件骨架。
通常编写组件需要编写如下代码
编写COM类并且实现IUnknown，这包括引用计数机制和接口查询机制
添加IDispatch或者双接口使得组建可用于脚本环境
编写一个类厂
自注册
适当的入口函数(DLL)或者注册(EXE)
选择适当的线程套间
如果你不使用任何类库，你需要负责上述代码的正确性。
MFC用于基于Windows的开发。如果你对MFC的根基——窗口过程和句柄的封装——有所了解，那么你可以避免编写老式的大型switch窗口过程。MFC还提供了广泛的编程模型，例如文档视图框架和活动文档，以及有用的用户界面，例如可停靠控制栏和切分窗口。
基于历史的原因，MFC和COM是基本上独立发展的。COM的普及使得MFC不得不在语言中加入OLE和COM支持——以一个相对繁琐的方式。MFC在CCmdTarget类中实现COM支持，使得程序员们可以用几个宏就可以声明和实现COM相关的操作。BEGIN_INTERFACE_PART和END_ INTERFACE_PART声明一个嵌套类，DECLARE_OLECREATE和IMPLEMENT_OLECREATE声明和实现一个类厂，用类似于消息映射的机制编写接口查询。这样做的优点是可以在派生类中重载一个接口的实现，坏处是需要为每个嵌套类编写自己的IUnknown实现。由于这样的实现很容易用宏实现，所以我觉得MFC居然没有提供这样的宏实在是一件很奇怪的事。
MFC是一个快速编写大型程序的框架，应用程序向导可以在几秒钟之内生成一个完全可以工作的应用程序骨架，而类向导生成消息处理和自动化代码是小菜一碟。MFC同时还有很好的OLE支持——拖放、扩展，活动文档——使得编写大型组件更加迅速。引入MFC的代价是大约1兆的内存，以及性能和发布的问题。
ATL是那些懒得一次又一次编写QueryInterface而又不想跟随控件那个很大的MFC运行时刻库的人搞出来的。ActiveX在网络上大行其道的时候，互联网的带宽还很小。尽管用MFC可以迅速开发ActiveX组件，但是MFC的再发布对于当时的网络是一个严重的问题。ATL是一个轻量级的框架，主要是提供了编写组件的向导、模板和宏，以及一些简单的平台SDK支持。用它可以迅速编写很小的组件和ActiveX控件，但是这也意味着程序员需要编写部分原来MFC封装了的代码，比如通用控件的操作。
不幸的是，一些观察者认为既然MFC和ATL都提供了COM支持，那么他们就是竞争者。通常这是错的。两个框架都提供了ActiceX控件向导，但是MFC的实现更加获益于类向导、平台SDK的封装和MFC架构——这也增加了需要发布的字节数——而ATL需要你对COM有更深的了解。ATL代码中平台SDK的操作更少——部分是因为复杂度，部分是因为MFC有更好的平台SDK封装——而COM的接口，例如容器、集合等等实现更多。
尽管ATL的应用程序向导中增加了MFC支持这个选项，但是引入MFC也失去了选择ATL的大部分理由——不需要发布那个好几兆的MFC支持库。建议的方式是参考MFC的源代码，尽可能自己实现需要的MFC类。
VB是快速开发的一个很好的工具。它自动替你实现了组件创建、接口查询、引用计数和组件的生命期问题。通常你要做的只是实现接口。同时如果你添加了一个到组件类型库的引用，那么你可以在自动完成功能中看到它会自动提示接口的成员。VB的优点在于快速开发，缺点是降低了灵活度，以及混淆了接口及其实现。区分接口及其实现是COM的核心之一。
总体来说，使用VB不需要对COM有深入的了解，而ATL提供了更多高级的COM支持。MFC是这两者之间的一个折衷，同时有大量的平台SDK封装和类向导可以利用。
老夏Max 2004-11-04
- 打赏
- 举报
两者的编译以后的文件大小也不一样，呵呵
老夏Max 2004-11-04
- 打赏
- 举报
先MFC，然后ATL。MFC让你知道为什么这么做，ATL让你快速的做！！
yu4233 2004-11-04
- 打赏
- 举报
说一些理由好吗？
posedge 2004-11-03
- 打赏
- 举报
ATL毫无疑问
yu4233 2004-11-03
- 打赏
- 举报
说一些理由好吗？
etre 2004-11-03
- 打赏
- 举报
ATL吧
