MFC、ATL、COM是否还有发展空间？

yemao4587

MFC是Win API与C++的结合,API,即微软提供的WinOS下应用程序的编程语言接口,是一种软件编程的规范,但不是一种程序开发语言本身,可以允许用户使用各种各样的第三方(如我是一方,微软是一方,Borland就是第三方)的编程语言来进行对Win OS下应用程序的开发,使这些被开发出来的应用程序能在WinOS下运行,比如VB,VC++,Java,Dehpi编程语言函数本质上全部源于API,因此用它们开发出来的应用程序都能工作在WinOS的消息机制和绘图里,遵守WinOS作为一个操作系统的内部实现,这其实也是一种必要,微软如果不提供API,这个世上对Win编程的工作就不会存在,微软的产品就会迅速从时尚变成垃圾,上面说到MFC是微软对API函数的专用C++封装,这种结合一方面让用户使用微软的专业C++ SDK来进行Win下应用程序的开发变得容易,因为MFC是对API的封装,微软做了大量的工作,隐藏了好多内节程序开发人员在Win下用C++ & MFC编制软件时的大量内节,如应用程序实现消息的处理,设备环境绘图,这种结合是以方便为目的的,必定要付出一定代价(这是微软的一向作风),因此就造成了MFC对类封装中的一定程度的的冗余和迂回,但这是可以接受的..
最后要明白MFC不只是一个功能单纯的界面开发系统,它提供的类绝大部分用来进行界面开发,关联一个窗口的动作,但它提供的类中有好多类不与一个窗口关联,即类的作用不是一个界面类,不实现对一个窗口对象的控制(如创建,销毁),而是一些在WinOS(用MFC编写的程序绝大部分都在WinOS中运行)中实现内部处理的类,如数据库的管理类等,学习中最应花费时间的是消息和设备环境,对C++和MFC的学习中最难的部分是指针,C++面向对像程序设计的其它部分,如数据类型,流程控制都不难,建议学习数据结构C++版..
---- 1 ．COM 的发展及其局限性
---- 自从1993 年Microsoft 首次公布了COM 技术以后，Windows 平台上的开发模式发生了巨大的变化， 以COM 为基础的一系列软件组件化技术将Windows 编程带入了组件化时代。 广大开发人员在为COM 带来的软件组件化趋势欢欣鼓舞的同时， 对于COM 开发技术的难度和烦琐的细节也感到极其的不便。COM 编程一度被视为一种高不可攀的技术， 令人望而却步。 开发人员希望能够有一种方便快捷的COM 开发工具， 提高开发效率， 更好地利用这项技术。
---- 针对这种情况，Microsoft 公司在推出COM SDK 以后， 为简化COM 编程， 提高开发效率， 采取了许多方案， 特别是在MFC（Microsoft Foundation Class） 中加入了对COM 和OLE 的支持。 但是随着Internet 的发展， 分布式的组件技术要求COM 组件能够在网络上传输， 而又尽量节约宝贵的网络带宽资源。 采用MFC 开发的COM 组件由于种种限制不能很好地满足这种需求， 因此Microsoft 在1995 年又推出了一种全新的COM 开发工具——ATL。
作者：恋恋宣言 0位粉丝 2006-7-17 11:49 回复此发言 2关于VC++中的MFC和ATL---- ATL 是ActiveX Template Library 的缩写， 它是一套C++ 模板库。 使用ATL 能够快速地开发出高效、 简洁的代码， 同时对COM 组件的开发提供最大限度的代码自动生成以及可视化支持。 为了方便使用， 从Microsoft Visual C++ 5.0 版本开始，Microsoft 把ATL 集成到Visual C++ 开发环境中。1998 年9 月推出的Visual Studio 6.0 集成了ATL 3.0 版本。 目前，ATL 已经成为Microsoft 标准开发工具中的一个重要成员， 日益受到C++ 开发人员的重视。
---- 在ATL 产生以前， 开发COM 组件的方法主要有两种： 一是使用COM SDK 直接开发COM 组件， 另一种方式是通过MFC 提供的COM 支持来实现。
---- 直接使用COM SDK 开发COM 组件是最基本也是最灵活的方式。 通过使用Microsoft 提供的开发包， 我们可以直接编写COM 程序。 但是， 这种开发方式的难度和工作量都很大， 一方面， 要求开发者对于COM 的技术原理具有比较深入的了解（ 虽然对技术本身的深刻理解对使用任何一种工具都是非常有益的， 但对于COM 这样一整套复杂的技术而言， 在短时间内完全掌握是很难的）；另一方面， 直接使用COM SDK 要求开发人员自己去实现COM 应用的每一个细节， 完成大量的重复性工作。 这样做的结果是， 不仅降低了工作效率， 同时也使开发人员不得不把许多精力投入到与应用需求本身无关的技术细节中。 虽然这种开发方式对于某些特殊的应用很有必要， 但这种编程方式并不符合组件化程序设计方法所倡导的可重用性， 因此， 直接采用COM SDK 不是一种理想的开发方式。
---- 使用MFC 提供的COM 支持开发COM 应用可以说在使用COM SDK 基础上提高了自动化程度， 缩短了开发时间。MFC 采用面向对象的方式将COM 的基本功能封装在若干MFC 的C++ 类中， 开发者通过继承这些类得到COM 支持功能。 为了使派生类方便地获得COM 对象的各种特性，MFC 中有许多预定义宏， 这些宏的功能主要是实现COM 接口的定义和对象的注册等通常在COM 对象中要用到的功能。 开发者可以使用这些宏来定制COM 对象的特性。
---- 另外， 在MFC 中还提供对Automation 和ActiveX Control 的支持， 对于这两个方面，Visual C++ 也提供了相应的AppWizard 和ClassWizard 支持， 这种可视化的工具更加方便了COM 应用的开发。
---- MFC 对COM 和OLE 的支持确实比手工编写COM 程序有了很大的进步。 但是MFC 对COM 的支持还不够完善和彻底， 例如对COM 接口定义的IDL 语言，MFC 并没有任何支持， 此外对于近些年来COM 和ActiveX 技术的新发展MFC 也没有提供灵活的支持。 这是由MFC 设计的基本出发点决定的。MFC 被设计成对Windows 平台编程开发的面向对象的封装， 自然要涉及Windows 编程的方方面面，COM 作为Windows 平台编程开发的一个部分也得到MFC 的支持， 但是MFC 对COM 的支持是以其全局目标为出发点的， 因此对COM 的支持必然要服从其全局目标。 从这个方面而言，MFC 对COM 的支持不能很好地满足开发者的要求。
---- 随着Internet 技术的发展，Microsoft 将ActiveX 技术作为其网络战略的一个重要组成部分大力推广， 然而使用MFC 开发的ActiveX Control， 代码冗余量大， 即所谓的“ 肥代码”（Fat Code），而且必须要依赖于MFC 的运行时刻库才能正确地运行。 虽然MFC 的运行时刻库只有部分功能与COM 有关， 但是由于MFC 的继承实现的本质，ActiveX Control 必须背负运行时刻库这个沉重的包袱。 如果采用静态连接MFC 运行时刻库的方式， 这将使ActiveX Control 代码过于庞大， 在网络上传输时将占据宝贵的网络带宽资源； 如果采用动态连接MFC 运行时刻库的方式， 这将要求浏览器一方必须具备MFC 的运行时刻库支持。 总之，MFC 对COM 技术的支持在网络应用的环境下也显得很不灵活。