微软软件开发技术二十年回顾（MFC篇）

 
　　三、 MFC篇

 

　　Windows API是面向过程的接口，因此对于当时的编程技术来说，它是完美无缺的。但是，随着人们逐渐使用C++进行Windows程序的开发，迫切需要建立与Windows API的面向对象包装的接口。1992年，微软将Windows API开发成为它的应用程序框架(AFX)，后来该产品又演变成为目前的微软基础类库(MFC)产品。下图2展示了MFC的顶级类层次结构。

　　
　　图2.MFC的类层次结构。

　　MFC为使用C++开发Windows GUI应用程序提供了一个十分全面的基础框架，它对以前的API进行了面向对象的科学包装，大大简化和加快了程序的开发。

　　Win95推出后出现在Visual C++ 4中的新版本的MFC 4.0使这个框架达到辉煌时期，在4.2版本时达到鼎盛。

　　MFC框架中引入了一种适应当时开发需求的典型的文档-视图机制，从而大大简化了程序开发。当然，要掌握这些框架结构绝非一日之功，其中还涉及到部分COM及大量的宏技术。也正由于这些方面，导致了业界对MFC的褒贬不一。但正如其它微软技术一样，这只能进一步促进微软继续改进这种技术。几十年的技术积累已经奠定了MFC的生存基础，即使Windows的Vista发布，MFC也不可能退出Windows的舞台。事实上，Vista之后的Visual Studio.NET仍将MFC作为一个重要的组成部分，在今年的Visual Studio.NET 2005中，MFC在C++中的位置依然如故。MFC的未来，应该不必担心，只要你深入考察.NET类库，你会发现，MFC的许多思想机制正悄然进入.NET。

　　新版的Visual C++.NET中MFC已经支持.NET开发了，而且MFC与ATL的协作更趋于和谐。如今你可以在Visual C++.NET中综合应用MFC、ATL与.NET库三者来开发应用程序，从而进一步增强C++开发的威力。

　　【补注】ATL框架与WTL框架

　　ATL即“ActiveX模板库”。它不能单独工作，是设计与Visual C++ V4.2，V5.0，V6.0一起工作的。

　　MFC和ATL都可以用来开发ActiveX控件。事实上，两者都支持各种开发向导和强有力的帮助类和模板，从而使控件的开发尽量简单。而且，这两种框架各有千秋。简言之，如果你相当熟悉MFC的各种机制而且是在创建庞大而成熟的图形应用程序本地控件或服务器控件，那么使用MFC书写控件时会有很大的优越性。

　　然而，用MFC建立的控件在执行时要求相应的MFC DLL支持，相应地导致体积庞大。如果在控件的规模成问题时，则可以考虑 使用另一种方法-ATL活动模板库。

　　在建立轻量级控件(几乎或根本没有用户界面要求的COM或DCOM服务器)时，ATL方法是MFC方法的替代方法。ATL在建立COM组件时使用了模板机制，这个框架对许多标准的COM接口提供了大量的模板。事实上，ATL根本不需要任何类型的运行时刻服务—由于以C++模板为基础，所以ATL对于外部库根本没有链接依赖性。因此，基于ATL的组件要比等价的基于MFC的控件占用的资源少。

　　WTL框架，作为ATL的扩展，也是由ATL小组开发的，包含在微软于2000年1月发布的开发平台SDK包中，虽然微软没有正式支持。WTL通过提供一个用于编写Win32应用程序和控件的轻量级的框架、一些特殊的视图、GDI对象和实用的类来扩展ATL窗口类。WTL的目标是成为最好和最简单的实现基于Win32和ATL的应用程序、服务器和控件的方法。