一. 什麼是ATL
自從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。
ATL是ActiveX Template Library 的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發出高效、簡潔的代碼（Effective and Slim code），同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用，從MicrosoftVisual C++5.0版本開始，Microsoft把ATL集成到Visual C++開發環境中。1998年9月推出的Visual Studio 6.0 集成了ATL 3.0版本。目前，ATL已經成為Microsoft標準開發工具中的一個重要成員，日益受到C++開發人員的重視。
ATL究竟給開發人員帶來了什麼樣的益處呢？這還要先從ATL產生以前的COM開發方式說起。
在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技術的支持在網路套用的環境下也顯得很不靈活。
解決上述COM開發方法中的問題正是ATL的基本目標。
首先ATL的基本目標就是使COM套用開發儘可能地自動化，這個基本目標就決定了ATL只面向COM開發提供支持。目標的明確使ATL對COM技術的支持達到淋漓盡致的地步。對COM開發的任何一個環節和過程，ATL都提供支持，並將與COM開發相關的眾多工具集成到一個統一的編程環境中。對於COM/ActiveX的各種套用，ATL也都提供了完善的Wizard支持。所有這些都極大地方便了開發者的使用，使開發者能夠把注意力集中在與套用本身相關的邏輯上。
其次，ATL因其採用了特定的基本實現技術，擺脫了大量冗餘代碼，使用ATL開發出來的COM套用的代碼簡練高效，即所謂的“Slim Code”。ATL在實現上儘可能採用最佳化技術，甚至在其內部提供了所有C/C++開發的程式所必須具有的C啟動代碼的替代部分。同時ATL產生的代碼在運行時不需要依賴於類似MFC程式所需要的龐大的代碼模組，包含在最終模組中的功能是用戶認為最基本和最必須的。這些措施使採用ATL開發的COM組件(包括ActiveX Control)可以在網路環境下實現套用的分散式組件結構。
第三，ATL的各個版本對Microsoft的基於COM的各種新的組件技術如MTS、ASP等都有很好的支持，ATL對新技術的反應速度大大快於MFC。ATL已經成為Microsoft支持COM套用開發的主要開發工具，因此COM技術方面的新進展在很短的時間內都會在ATL中得到反映。這使開發者使用ATL進行COM編程可以得到直接使用COM SDK編程同樣的靈活性和強大的功能。
本文的目的就是希望在有限的篇幅中能夠使讀者對ATL的使用和基本原理有一個初步的了解，為廣大的COM開發人員更好地使用ATL開發起到拋磚引玉的作用。
