C++ MFC ALT CLR （转）

ATL是ActiveXTemplateLibrary的缩写，它是一套C++模板库。使用ATL能够快速地开发出高效、简洁的代码，同时对COM组件的开发提供最大限度的代码自动生成以及可视化支持。为了方便使用，从MicrosoftVisualC++5.0版本开始，Microsoft把ATL集成到VisualC++开发环境中。1998年9月推出的VisualStudio6.0集成了ATL3.0版本。
在ATL产生以前，开发COM组件的方法主要有两种：一是使用COMSDK直接开发COM组件，另一种方式是通过MFC提供的COM支持来实现。
直接使用COMSDK开发COM组件是最基本也是最灵活的方式。通过使用Microsoft提供的开发包，我们可以直接编写COM程序。但是，这种开发方式的难度和工作量都很大，一方面，要求开发者对于COM的技术原理具有比较深入的了解（虽然对技术本身的深刻理解对使用任何一种工具都是非常有益的，但对于COM这样一整套复杂的技术而言，在短时间内完全掌握是很难的）；另一方面，直接使用COMSDK要求开发人员自己去实现COM应用的每一个细节，完成大量的重复性工作。这样做的结果是，不仅降低了工作效率，同时也使开发人员不得不把许多精力投入到与应用需求本身无关的技术细节中。虽然这种开发方式对于某些特殊的应用很有必要，但这种编程方式并不符合组件化程序设计方法所倡导的可重用性，因此，直接采用COMSDK不是一种理想的开发方式。
使用MFC提供的COM支持开发COM应用可以说在使用COMSDK基础上提高了自动化程度，缩短了开发时间。MFC采用面向对象的方式将COM的基本功能封装在若干MFC的C++类中，开发者通过继承这些类得到COM支持功能。为了使派生类方便地获得COM对象的各种特性，MFC中有许多预定义宏，这些宏的功能主要是实现COM接口的定义和对象的注册等通常在COM对象中要用到的功能。开发者可以使用这些宏来定制COM对象的特性。
随着Internet技术的发展，Microsoft将ActiveX技术作为其网络战略的一个重要组成部分大力推广，然而使用MFC开发的ActiveXControl，代码冗余量大，即所谓的“肥代码”（FatCode），而且必须要依赖于MFC的运行时刻库才能正确地运行。虽然MFC的运行时刻库只有部分功能与COM有关，但是由于MFC的继承实现的本质，ActiveXControl必须背负运行时刻库这个沉重的包袱。如果采用静态连接MFC运行时刻库的方式，这将使ActiveXControl代码过于庞大，在网络上传输时将占据宝贵的网络带宽资源；如果采用动态连接MFC运行时刻库的方式，这将要求浏览器一方必须具备MFC的运行时刻库支持。总之，MFC对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的支持不能很好地满足开发者的要求。

对于程序员来说，还有一个区别就是ATL要求你懂得更多的COM知识，这样你才能直接使用ATL来编写COM组件或者控件，而MFC甚至不要求你知道COM是个什么东西就能写出一个ActiveX控件来了。
此外，如果你编写的控件有GUI（图形用户界面）的话，你最好使用MFC；如果根本不需要GUI，那最好使用ATL编写，当然你也可以选择MFC来编写不可见的控件，但是开销比ATL大，而执行效率却小于ATL；但是有时候这种差别所带来影响可以忽略掉的话，那么我建议你还是用MFC来写，唯一的理由是它开发起来更简单，易于调试。如果你是一个COM的门外汉，却又想使用ATL来编写控件，那么建议你先准备半年时间（保守估计）来学习COM的理论知识

简单地说,ATL在网络应用普及的今天,开发效果(简洁\高效)要比MFC好.但我本人觉得MFC也不差!我一直在用MFC做事!

===============================================

MFC、ATL和CLR是VC2005内置的3大库，涵盖了windows的各种开发方法和开发应用。当然关于C++开发的库不止这3个，不过这3个是微软推荐。从编程所处层次而言，WIN32为最底层,其次是MFC.然后是CLR. WIN32 winAPI MFC MFC类库 CLR .net库
1. WIN32常规就是不用MFC，使用API函数编的程序。
2. MFC库有很多年的历史了，MFC是基于Windows API 的简单封装。其核心架构基于"Document/View"架构（20年前被认为很潮流的一种概念）和消息流动机制。这个库自从VC6开始到现在都没有多大改动。MFC封装的范围包括GUI，IO，数据库，网络编程等等方面。但是很多系统开发必须的api都没有封装，这样开发者一般都在MFC的基础上自己处理与业务相关的任务。事实上很多人用MFC只是利用其GUI部分的封装。这个库GUI处理的效率也并不是很高，有时候与UI处理相关的代码会占到整个项目的一半甚至更多。总的来说，这是一个垂老的库，微软在10年以来，除了对MFC进行修修补补以外，没有进行大的改进或者更新。如果你问MFC还会活多久？恩，这是个问题。如果有一天MFC不在了，微软在这个级别上并没有其他产品能够代替它。
3. CLR库是随着.Net Framework 2 和VS2005一起发布的库，其核心的实现和C#，VB.net 一样。都是基于公共语言运行库。.Net Framework封装了大量系统的api，以类库的形式提供给开发者。C++中的CLR库可以使用其中和本机代码有关的部分，目前C++还不能涉及到asp.net部分。CLR库中的C++颠覆了很多标准C++的传统，甚至可以说，这里的C++不是C++，只是披着C++的皮干其他的事。这里的C++更像是C#或者类似的语言。所以这里不叫C++，而叫做C++/CLI，值得一提的是，有关C++/CLI的部分目前还没有被标准C++接受，最近微软有关C++/CLI标准化的提案被C++标准化委员会拒绝了。所以C++/CLI目前还是微软的一家之言。
4. ATL用于编写COM程序。ATL库貌似也年纪很大了，至少在我接触到VC的时候就有它的存在了。这个库可以追溯到COM组件，因为ATL的目的就是帮助开发者更好的与COM交互。到底什么时候有COM这个东西的 ？我也不知道，我只知道COM是有16位版本的，在Windows升级到32位的时候COM也随着升级到了32位。COM就像一些封装好的类对象一样，通过封装系统的api，提供一些标准的方法来给你使用。所以系统中有什么组件，就可以在ATL中用什么方法 。所以ATL不止可以写ActiveX，也可以有window，也可以有其它。有时候有些微软发布的功能是只以COM组件的形式发布的，例如MSXML，这时候MFC就不适合，是要ATL来处理的。但是ATL在处理UI这方面并不是很强，所以微软工程师有一个开源的UI 框架，叫做WTL，专门用来处理UI的。ATL库的缺点是，作为模板库，在出现错误的时候会比较麻烦，出错提示会牛头不对马嘴。