为什么使用ATL?
ATL是在单层（single-tier）应用逐渐过时，分布式应用逐渐成为主流这样一个环境中诞生的， 它最初的版本是在四个C++头文件中，其中有一个还是空的。它所形成的出色的构架专门用于开发现代分布式应用所需的轻量级COM组件。作为一个模块化的标准组件，ATL不像MFC有厚重的基础结构，省时好用的库使得成百上千的程序员一次又一次轻松实现IUnknown 和IClassFactory。
ATL的构架并不打算包罗万象，无所不能。其第一个版本对实现IUnknown，IClassFactory，IDispatch，IconnectionPointContainer及COM枚举提供非常 到位的支持。第二个版本除了可以编写ActiveX控件外，还对最初的第一个版本中ATL类进行了增强。ATL不提供集合（collections）和串（strings）的处理 ，它假设你用标准的C++库进行这些处理；不支持ODBC――这个世界正在转移到基于COM的不需要包装的数据存取方式；不支持WinSock打包类--sockets本身也是新的东西；ATL也不支持完整的Win32 API打包类――ATL2.0的实现机制提供了对话框和WndProcs支持。此外ATL中没有MFC中的文档/视图模型。取而代之的是ATL那更具伸缩性和灵活 性的通过COM接口（如ActiveX控件）与基于UI的对象之间的沟通模式。
使用正确的工具非常关键。如果你正在编写一个不可见的COM组件，那么ATL与MFC比起来，从开发效率，可伸缩性，运行时性能以及可执行文件大小各方面来看，ATL可能 都是最好的选择。对于现代基于ActiveX控件的用户界面，ATL所产生的代码也比MFC更小更快。另一方面，与MFC的类向导相比，ATL需要更多的COM知识。ATL与STL一样，对于单层应用没什么帮助，而MFC在这方面保持着它的优势。
ATL的设计在很大程度上来自STL的灵感，STL与所有ANSI/ISO兼容的C++编译器一起已经被纳入成为标准C++库的一部分。像STL一样，ATL大胆使用C++模板。模板是C++中众多具有争议的特性之一。每每使用不当都会导致执行混乱，降低性能 和难以理解的代码。明智地使用模板所产生的通用性效果和类型安全特性则是其它方法所望尘莫及的。ATL与STL一样陷入了两个极端。幸运的是 在L大胆使用C++模板的同时，编译器和链接器技术也在以同样的步伐向前发展。为当前和将来的开发进行STL和ATL的合理选择。尽管模板在内部得到广泛的使用，但是在用ATL技术时，你不用去敲入或关心那些模板中的尖括弧。因为ATL本身带有ATL对象向导（参见图一）：
图一 ATL 对象向导
对象向导产生大量基于ATL模板类缺省的对象实现代码（即框架代码）。这些缺省的对象类型如附表一所列。ATL对象向导允许任何人 快速建立COM对象并且在分分钟之内让它运行起来，不用去考虑COM或ATL的细节问题。当然，为了能充分驾驭ATL，你必须掌握C++，模板和COM编程技术。对于大型的对象类，只要在ATL对象向导所产生的缺省实现（框架代码）中加入方法实现来输出定制接口，这也是大多数开发人员开始实现COM对象时的重点所在。
初次接触ATL时，其体系结构给人的感觉是神秘和不可思议。HelloATL是一个最简单的基于ATL的进程内服务器源代码 以及用SDK（纯粹用C++编写）实现的同样一个进程内服务器源代码。在真正构建出一个COM组件之前，代码需要经过反反复复多次斟酌和修改。对于想加速开发COM组件速度的主流组件开发人员来说，ATL体系结构并不是什么大问题，因为对象向导产生了所需要的全部框架代码，只 要你加入方法定义即可。对于认真的COM开发人员和系统编程人员来说，ATL提供了一个用C++建立COM组件的高级的，可扩展的体系结构。一旦你理解和掌握了这个体系结构并能驾驭对象向导，你就会看到ATL的表现能力和强大的功能 ，它完全可以和原始的COM编程技术媲美。
另外一个使用ATL开发COM组件的理由是Visual C++ 5.0+集成开发环境（IDE）对ATL的高度支持。 微软在Visual C++ 5.0+中将ATL所要用到的接口定义语言（IDL）集成到了C++编辑器中。（待续）