《VC++ 的MFC 和ATL 及COM 的基本概念解析》由会员分享，可在线阅读，更多相关《VC++ 的MFC 和ATL 及COM 的基本概念解析（5页珍藏版）》请在金锄头文库上搜索。
1、VC+的MFC和ATL及COM的基本概念解析一、什么是MFC微软基础类（Microsoft Foundation Classes），实际上是微软提供的,用于在 C+环境下编写应用程序的一个框架和引擎,VC+是WinOS下开发人员使用的 专业 C+ SDK（SDK,Standard Software Develop Kit,专业软件开发平台）,MFC 就是 挂在它之上的一个输助软件开发包,MFC作为与VC+血肉相连的部分（注意C+ 和VC+的区别:C+是一种程序设计语言，是一种大家都承认的软件编制的通用 规范,而VC+只是一个编译器,或者说是一种编译器+源程序编辑器的 IDE,WS,PlatFo
2、rm，这跟Pascal和Dephi的关系一个道理,Pascal是Dephi的语言基 础,Dephi使用Pascal规范来进行Win下应用程序的开发和编译,却不同于Basic 语言和VB的关系,Basic语言在VB开发出来被应用的年代已经成了 Basic语言 的新规范,VB新加的Basic语言要素，如面对对象程序设计的要素,是一种性质上 的飞跃，使VB既是一个IDE,又成长成一个新的程序设计语言）,MFC同BC+集成 的VCL 一样是一个非外挂式的软件包，类库，只不过MFC类是微软为VC+专配 的.MFC是Win API与C+的结合,API,即微软提供的WinOS下应用程序的编程语言 接口，是一
3、种软件编程的规范,但不是一种程序开发语言本身，可以允许用户使用 各种各样的第三方（如我是一方，微软是一方,Borland就是第三方）的编程语言来进 行对Win OS下应用程序的开发,使这些被开发出来的应用程序能在WinOS下运 行，比如VB,VC+,Java,Dehpi编程语言函数本质上全部源于API,因此用它们开发 出来的应用程序都能工作在WinOS的消息机制和绘图里，遵守WinOS作为一个 操作系统的内部实现,这其实也是一种必要，微软如果不提供API,这个世上对Win 编程的工作就不会存在，微软的产品就会迅速从时尚变成垃圾，上面说到MFC是 微软对API函数的专用C+封装，这种结合一方面让
4、用户使用微软的专业C+ SDK来进行Win下应用程序的开发变得容易，因为MFC是对API的封装，微软做 了大量的工作，隐藏了好多内节程序开发人员在Win下用C+ & MFC编制软件 时的大量内节，如应用程序实现消息的处理，设备环境绘图,这种结合是以方便为 目的的,必定要付出一定代价（这是微软的一向作风），因此就造成了 MFC对类封装 中的一定程度的的冗余和迂回，但这是可以接受的.最后要明白MFC不只是一个功能单纯的界面开发系统，它提供的类绝大部分用 来进行界面开发,关联一个窗口的动作，但它提供的类中有好多类不与一个窗口关 联，即类的作用不是一个界面类，不实现对一个窗口对象的控制（如创建,销毁）
5、，而 是一些在WinOS（用 MFC编写的程序绝大部分都在WinOS中运行）中实现内部处 理的类，如数据库的管理类等,学习中最应花费时间的是消息和设备环境，对C+ 和MFC的学习中最难的部分是指针,C+面向对像程序设计的其它部分,如数据 类型，流程控制都不难，建议学习数据结构C+版.、什么是COM-COM的发展及其局限性所谓COM （Componet Object Model，组件对象模型），是一种说明如何 建立可动态互变组件的规范，此规范提供了为保证能够互操作，客户和组件应遵 循的一些二进制和网络标准。通过这种标准将可以在任意两个组件之间进行通信 而不用考虑其所处的操作环境是否相同、使用的开
6、发语言是否一致以及是否运行 于同一台计算机。COM的优点？首先：用户一般希望能够定制所用的应用程序，而组件技术从本质上讲 就是可被定制的，因而用户可以用更能满足他们需要的某个组件来替换原来的那 个。其次，由于组件是相对应用程序独立的部件，我们可以在不同的程序中使用 同一个组件而不会产生任何问题，软件的可重用性将大大的得到增强。第三，随 着网络带宽及其重要性的提高，分布式网络应用程序毫无疑问的成为软件市场上 越来越重要的买点。组件价构可以使得开发这类应用程序的过程得以简化。什么是COM+？M+并不是 COM的简单升级，COM+的底层结构仍然以COM为基础， 它几乎包容了 COM的所有内容，COM
7、+综合了 COM、DCOM和MTS这些技术 要素，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作 系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给 操作系统，因此，COM+与操作系统的结合更加紧密。COM+不再局限于COM的组件技术，它更加注重于分布式网络应用的设 计和实现。COM+继承了 COM几乎全部的优势，同时又避免了 COM实现方面 的一些不足，把COM、DCOM和MTS的编程模型结合起来，继承了它们的绝 大多数特性，在原有的特性上增加了新的功能。COM+的新的优点？以下列出COM+的几个主要特性：COM+不仅继承了 COM所有的优点，而且还增加
8、了一些服务，比如 队列服务、负载平衡、内存数据库、事件服务等。队列服务对于分布式应用非常有意义，特别是在现在网络速度很慢的情况 下，这种机制可以保证应用系统能够可靠地运行。在应用系统包含大量节点但服 务器又繁忙的情况下，客户应用程序可以把它们的请求放到队列中，当服务器负 载比较轻的时候再处理这些请求；又如COM+提供了负载平衡服务，它可以实现动态负载平衡，而且COM+ 应用程序的负载平衡特性并不需要编写代码来支持，客户程序和组件程序都可以 按通常的方式实现。获得负载平衡特性并不是用程序设计的方式来实现的，而是 通过配置实现分布式应用程序的负载平衡，如上所讲的队列服务，其实也反映了一种负载平衡。
9、(1) 真正的异步通讯。COM+底层提供了队列组件服务，这使客户和组件有 可能在不同的时间点上协同工作，COM+应用无须增加代码就可以获得这样的特 性。(2) 事件服务。新的事件机制使事件源和事件接收方实现事件功能更加灵 活，利用系统服务简化了事件模型，避免了 COM可连接对象机制的琐碎细节。(3) 可伸缩性。COM+的可伸缩性来源于多个方面，动态负载平衡以及内存 数据库、对象池等系统服务都为COM+的可伸缩性提供了技术基础，COM+的可 伸缩性原理上与多层结构的可伸缩特性一致。(4) 可管理和可配置性。管理和配置是应用系统开发完成后的行为，在软 件维护成本不断增加的今天，COM+应用将有助于
10、软件厂商和用户减少这方面的 投入。(5) 易于开发COM+应用开发的复杂性和难易程度将决定COM+的成功与 否，虽然COM+开发模型比以前的COM组件开发更为简化，但真正提高开发效 率仍需要借助于一些优秀的开发工具。COM+标志着Microsoft的组件技术达到了一个新的高度，它不再局限于 一台机器上的桌面系统，它把目标指向了更为广阔的企业内部网，甚至Internet 国际互连网络COM+与多层结构模型以及Windows操作系统为企业应用或Web 应用提供了一套完整的解决方案。三、什么是ATL自从1993年Microsoft首次公布了 COM技术以后，Windows平台上的开发模 式发生了巨大
11、的变化，以COM为基础的一系列软件组件化技术将Windows编程 带入了组件化时代。广大开发人员在为COM带来的软件组件化趋势欢欣鼓舞的 同时，对于COM开发技术的难度和烦琐的细节也感到极其的不便。COM编程 一度被视为一种高不可攀的技术，令人望而却步。开发人员希望能够有一种方便 快捷的COM开发工具，提高开发效率，更好地利用这项技术。-针对这种情况，Microsoft公司在推出COMSDK以后，为简化COM编程，提 高开发效率，采取了许多方案，特别是在MFC(MicrosoftFoundationClass)中加 入了对COM和OLE的支持。但是随着Internet的发展，分布式的组件技术要
12、求 COM组件能够在网络上传输，而又尽量节约宝贵的网络带宽资源。采用MFC 开发的COM组件由于种种限制不能很好地满足这种需求，因此Microsoft在1995 年又推出了一种全新的COM开发工具ATL。ATL是ActiveXTemplateLibrary的缩写，它是一套C+模板库。使用ATL能 够快速地开发出高效、简洁的代码，同时对COM组件的开发提供最大限度的代 码自动生成以及可视化支持。为了方便使用，从MicrosoftVisualC+5.0版本开始， Microsoft把ATL集成到VisualC+开发环境中。1998年9月推出的VisualStudio6.0 集成了 ATL3.0版本
13、。目前，ATL已经成为Microsoft标准开发工具中的一个重 要成员，日益受到C+开发人员的重视。-ATL究竟给开发人员带来了什么样的益处呢？这要先从 ATL产生以前的 COM开发方式说起。-在ATL产生以前，开发COM组件的方法主要有两种：一是使用COMSDK 直接开发COM组件，另一种方式是通过MFC提供的COM支持来实现。-直接使用COMSDK开发COM组件是最基本也是最灵活的方式。通过使用 Microsoft提供的开发包，我们可以直接编写COM程序。但是，这种开发方式的 难度和工作量都很大，一方面，要求开发者对于COM的技术原理具有比较深入 的了解（虽然对技术本身的深刻理解对使用任何
14、一种工具都是非常有益的，但对 于COM这样一整套复杂的技术而言，在短时间内完全掌握是很难的）；另一方 面，直接使用COMSDK要求开发人员自己去实现COM应用的每一个细节，完 成大量的重复性工作。这样做的结果是，不仅降低了工作效率，同时也使开发人 员不得不把许多精力投入到与应用需求本身无关的技术细节中。虽然这种开发方 式对于某些特殊的应用很有必要，但这种编程方式并不符合组件化程序设计方法 所倡导的可重用性，因此，直接采用COMSDK不是一种理想的开发方式。-使用MFC提供的COM支持开发COM应用可以说在使用COMSDK基础上 提高了自动化程度，缩短了开发时间。MFC采用面向对象的方式将COM
15、的基 本功能封装在若干MFC的C+类中，开发者通过继承这些类得到COM支持功 能。为了使派生类方便地获得COM对象的各种特性，MFC中有许多预定义宏， 这些宏的功能主要是实现COM接口的定义和对象的注册等通常在COM对象中 要用到的功能。开发者可以使用这些宏来定制COM对象的特性。另外，在 MFC中还提供对Automation和ActiveXControl的支持，对于这两 个方面，VisualC+也提供了相应的AppWizard和ClassWizard支持，这种可视化 的工具更加方便了 COM应用的开发。-MFC对COM和OLE的支持确实比手工编写COM程序有了很大的进步。但 是MFC对COM
16、的支持还不够完善和彻底，例如对COM接口定义的IDL语言， MFC并没有任何支持，此外对于近些年来COM和ActiveX技术的新发展MFC 也没有提供灵活的支持。这是由MFC设计的基本出发点决定的。MFC被设计成 对Windows平台编程开发的面向对象的封装，自然要涉及Windows编程的方方 面面，COM作为Windows平台编程开发的一个部分也得到MFC的支持，但是 MFC对COM的支持是以其全局目标为出发点的，因此对COM的支持必然要服 从其全局目标。从这个方面而言，MFC对COM的支持不能很好地满足开发者 的要求。随着Internet技术的发展，Microsoft将ActiveX技术作为其网络战略的一个重 要组成部分大力推广，然而使用MFC开发的ActiveXContro 1，代码冗余量大， 即所谓的“肥代码”（FatC
